2

全部，

所以我将一个文本文件从 C# 上传到 IBM MVS 大型机。该文件使用 C# 库转换为 ebcdic，它运行良好，因为我可以读取大型机上的数据。问题是新线路。文本文件有 10 行数据，在大型机环境中查看时，所有数据都存在。但是没有新行，因为它将文本文件中的每一行转换为 0D25，即 CRLF。该片段在屏幕上显示为 ..。
我不想要具有 0D25 十六进制读数的 2 个点，因为我需要它将数据实际放置在下一行，就像它在文本文件中一样。顺便说一句，该文件在大型机上一次是可变块长度。在 MVS 上查看上传的文件时，如何实现与文本文件相同的格式？

示例：文本文件视图

12345
23456
12346


IBM MAinFrame 视图

12345..23456..12346

或者如果已经达到块长度..

12345..2345
6..12346

谢谢

4

1 回答 1

5

如果您在 FTP 传输过程之外进行 ASCII-EBCDIC 转换，我必须假设您正在以二进制模式传输（否则将再次进行转换并且您的数据会很糟糕）。

如果是这种情况，那么我很确定您自己也要对行尾的转换负责。二进制传输不会尝试转换行尾。在将其发送到主机之前，您需要将行填充到所需的长度并完全删除行尾。

例如，如果您传输此文件：

12345
67890

在二进制模式下使用literal site recfm=vb，您将获得以下信息（在 ISPF 编辑器中显示为hex on）：

000001                    
       3333300333330044444
       12345DA67890DA00000
--------------------------

您可以看到它只是按原样传输字节，包括 CR/LF。如果您在 FTP 中切换到 ASCII 模式并再次上传，您会得到：

000001 12345        
       FFFFF44444444
       1234500000000
--------------------
000002 67890        
       FFFFF44444444
       6789000000000
--------------------

在这里，字符已转换为正确的 EBCDIC 代码点，并且行尾已变形为带有 EBCDIC 空格的填充。

我想我对您的第一个问题是：“您为什么要在 FTP 之外进行翻译？”

IBM 投入了大量资金来确保它能够接受各种不同的编码并将它们转换为正确的代码页。一个独立的解决方案不太可能适用于所有国际化版本的 z/OS 以及 IBM 自己的版本。

如果您必须在客户端上进行转换并以二进制模式传输，则必须让客户端也进行行结束转换和填充，或者在传输后对文件进行后处理，例如使用 REXX 脚本。

如果您不知道目标数据集的属性是什么（例如，如果您要转移到 PDS 中的成员），则后一种选择可能是唯一可行的选择。

于 2010-08-30T04:51:40.403 回答