大型机迁移到 USS/Github

Posted 2023-02-16

【中文标题】大型机迁移到 USS/Github

【英文标题】：Mainframe Migration to USS/Github

【发布时间】：2020-09-11 07:17:58

【问题描述】：

我们正在尝试将程序（不是文件）从大型机迁移到 USS，然后最终迁移到 Github。

我们有一个程序在迁移过程中出现问题。这些程序包含十六进制字符，并且在从 Mainframe PDS 到 Unix 的传输过程中被重新格式化。有没有我可以插入的命令，以便 Unix 在从 MF PDS 传输期间不会重新格式化这些值？

编辑： 程序包含 EBCDIC 字符 x'15'（换行符）和 x'0D'（回车），在传输文件时会在文件中引入空格 x'40' 从 z/OS 到 USS。这些填充的 x'40's 将其余字符推入下一行。

我正在使用以下命令从大型机传输到 Unix。此命令由批处理代理在大型机内触发。

cp -U -S a=.CPY  -T -O c=IBM-1047  "//'Insert PDS Here'" /data/Github

有问题的 2 代码 sn-p 具有以下十六进制值，十六进制值从 00 - 0F 和 10 - 1F 开始

444444444444444444444444444444444444470000000000000000744444444444
0000000000000000000000000000000000000D0123456789ABCDEFDB0000000000

444444444444444444444444444444444444471111111111111111744444444444
0000000000000000000000000000000000000D0123456789ABCDEFDB0000000000

在 iDZ 中查看时，Unix 用新行重新格式化

重新格式化的行

【问题讨论】：

请edit您的问题并添加更多详细信息。我假设您在 z/OS 上运行 cp 命令。请在问题中确认这一点。文件包含哪些数据？十六进制数据是二进制数据的十六进制转储吗？如何将文件传输到 UNIX 系统？您是否转换了字符编码？如果是，如何？您使用什么命令/程序在 UNIX 系统上显示文件？或者您是否使用大型机上的程序从 UNIX 文件系统远程显示文件？后一种情况，可能是UNIX文件系统无法存储标签信息-O c=IBM-1047？

您好，Bodo，我已经根据您的问题提供了尽可能多的信息来编辑问题。至于 -O c=IBM-1047，由于 Cobol Codes 中唯一有问题的程序部分是 Padded x'15' 和 x'0D'，因此 1000 多个 Cobol 代码的其余部分没有问题

@UnixNoob 我将您的代码 sn-p 放入 PDS 的成员中，并使用您显示的相同命令行。 USS 中复制的文件与 PDS 的成员具有完全相同的内容，除了在行尾添加了换行符（即x'15'）。我使用 FB 和 VB 数据集进行了此测试，并且都产生了相同的结果，因此在复制到 USS 文件时我没有看到任何重新格式化。但是，如果您使用 USS cat 命令来显示文件的内容，它将在您的代码 sn-p 中的 x'15' 字符处拆分文本，这是正确的行为。

@MilosLalovic - 我们正在使用 iDZ 直接查看，线路已重新格式化。当我们将代码从 USS 推送到 GutHub 时，这种重新格式化也很明显。此外，当我们尝试将代码推送回大型机时，重新格式化仍然存在。

如果 iDZ 代码页转换器出现问题，尽管我认为问号应该出现在代码 sn-p 中的不可打印字符上。如果上传到 GitHub 导致内容错误，那也是代码页转换器问题。

【参考方案1】：

在过去，在 1985 年标准之前，COBOL 不允许使用十六进制文字。那时，在需要时，程序员会将十六进制值直接输入到编辑器中。一些程序员没有得到备忘录，并继续以这种方式做事。除了旧方式之外，任何受支持的大型机 COBOL 编译器现在都将允许使用十六进制文字。

我建议修改有问题的 COBOL 程序源代码行以阅读

       05  FILLER PIC X(16) 
           VALUE X'000102030405060708090A0B0C0D0E0F'.

【讨论】：

不幸的是，代码是高效的，并且由于时间限制、范围和测试工作，编辑组件不是我们的选择。现在