Fatal编程技术网
  • migration/
  • Migration 大型机迁移到USS/Github

Migration 大型机迁移到USS/Github

migration

Migration 大型机迁移到USS/Github,migration,hex,mainframe,Migration,Hex,Mainframe,我们正在尝试将程序（而不是文件）从大型机迁移到USS，然后最终迁移到Github 我们有一个程序在迁移过程中出现问题。这些程序包含十六进制字符，在从大型机PDS传输到Unix的过程中正在重新格式化。是否有可以插入的命令，以便Unix在从MF PDS传输期间不会重新格式化值 编辑： 该程序包含EBCDIC字符x'15'（换行符）和x'0D'（回车符），在传输文件时将空格x'40'引入文件 从z/OS到USS。这些加垫的x'40将其余字符推入下一行 我正在使用下面的命令从大型机传输到Unix。此命令

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

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

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

  • 我正在使用下面的命令从大型机传输到Unix。此命令在大型机内由批处理代理触发
  • 出现问题的2个代码段下面有一个十六进制值，十六进制值从00-0F和10-1F开始
    • 444444444 70000000000000074444444
0000000000000000000000000000000 D0123456789ABCDEFDB0000000000
444444444444444444444444444444444444471111111111111111744444444444
0000000000000000000000000000000 D0123456789ABCDEFDB0000000000
  • 在iDZ中查看Unix时，使用新行重新格式化
    • 重新格式化的行

    在1985年标准之前的旧时代，COBOL不允许十六进制文字。那时，当需要时，程序员会直接在编辑器中输入十六进制值。一些程序员没有收到备忘录，继续这样做。除旧方法外，任何受支持的大型机COBOL编译器现在都将允许十六进制文本

    我建议将有问题的COBOL程序源代码行修改为

           05  FILLER PIC X(16) 
           VALUE X'000102030405060708090A0B0C0D0E0F'.
    在1985年标准之前的旧时代，COBOL不允许十六进制文字。那时，当需要时，程序员会直接在编辑器中输入十六进制值。一些程序员没有收到备忘录，继续这样做。除旧方法外，任何受支持的大型机COBOL编译器现在都将允许十六进制文本

    我建议将有问题的COBOL程序源代码行修改为

           05  FILLER PIC X(16) 
           VALUE X'000102030405060708090A0B0C0D0E0F'.
    请回答您的问题并添加更多详细信息。我假设您在z/OS上运行
    cp
    命令。请在问题中确认这一点。文件包含哪些数据？十六进制数据是二进制数据的十六进制转储吗？如何将文件传输到UNIX系统？你转换了字符编码吗？如果是，如何进行？您使用什么命令/程序在UNIX系统上显示文件？还是使用大型机上的程序从UNIX文件系统远程显示文件？在后一种情况下，可能UNIX文件系统无法存储标记信息
    -O c=IBM-1047
    ？您好，我已经根据您的问题编辑了这个问题，并提供了尽可能多的信息。至于-O c=IBM-1047，由于Cobol代码中唯一存在问题的程序部分是填充的x'15'和x'0D'，因此1000多个Cobol代码中的其余部分没有问题issue@UnixNoob我将您的代码片段放入PDS的一个成员中，并使用了与您显示的相同的命令行。USS中复制的文件的内容与PDS的成员完全相同，只是在行尾添加了新行字符（即
    x'15'
    ）。我使用FB和VB数据集进行了此测试，两者都产生了相同的结果，因此在复制到USS文件时，我没有看到任何重新格式化。但是，如果使用USS
    cat
    命令显示文件内容，它将在代码段中的
    x'15'
    字符处拆分文本，这是正确的行为。@Miloslovic-我们正在使用iDZ直接查看，并且该行已重新格式化。当我们将代码从USS推送到GutHub时，这种重新格式化也很明显。此外，当我们尝试将代码推回到大型机时，重新格式化仍然存在。如果iDZ代码页转换器中存在问题，则可能会出现问题，尽管我认为代码片段中不可打印的字符应该出现问号。如果上传到GitHub导致内容错误，这也将是一个代码页转换器问题。请回答您的问题并添加更多详细信息。我假设您在z/OS上运行
    cp
    命令。请在问题中确认这一点。文件包含哪些数据？十六进制数据是二进制数据的十六进制转储吗？如何将文件传输到UNIX系统？你转换了字符编码吗？如果是，如何进行？您使用什么命令/程序在UNIX系统上显示文件？还是使用大型机上的程序从UNIX文件系统远程显示文件？在后一种情况下，可能UNIX文件系统无法存储标记信息
    -O c=IBM-1047
    ？您好，我已经根据您的问题编辑了这个问题，并提供了尽可能多的信息。至于-O c=IBM-1047，由于Cobol代码中唯一存在问题的程序部分是填充的x'15'和x'0D'，因此1000多个Cobol代码中的其余部分没有问题issue@UnixNoob我将您的代码片段放入PDS的一个成员中，并使用了与您显示的相同的命令行。USS中复制的文件的内容与PDS的成员完全相同，只是在行尾添加了新行字符（即
    x'15'
    ）。我使用FB和VB数据集进行了此测试，两者都产生了相同的结果，因此在复制到USS文件时，我没有看到任何重新格式化。但是，如果使用USS
    cat
    命令显示文件内容，它将在代码段中的
    x'15'
    字符处拆分文本，这是正确的行为。@Miloslovic-我们正在使用iDZ直接查看，并且该行已重新格式化。当我们将代码从USS推送到GutHub时，这种重新格式化也很明显。此外，当我们试图将代码推回到大型机时，重新格式化仍然存在。如果出现问题，可能是在iDZ代码页转换器中，尽管我认为问号应该是