Ftp TSO/MVS上传问题

我正在将一个ebcdic文件（从ascii转换）从Windows操作系统上载到大型机。我的问题是，当我上传文件后检查它时，我看到很多新行。

---

当我试图用它的十六进制转储文件检查它时，我发现当大型机看到一个x'15'时，它会把它转换成一个新行。文件中有压缩的小数，所以十六进制可以包含x'001500001c'，但当我上传它时，大型机误认为它是一个新行。有人能帮我解决这个问题吗？

如果您发送的文件已经是EBCDIC格式的，您应该将您的FTP客户端（或库，如果上传是由您的代码完成的）置于二进制（图像类型）模式，而不是ascii/EBCDIC模式。

这取决于您上传到的目标“文件”的类型

如果要上载到具有固定块大小（例如FB80）的成员，则需要确保在向上传输之前（以二进制模式）所有行都填充了空格

文本模式传输不适用于二进制文件（如果文件包含压缩小数，则文件为二进制文件-FTP无法可靠地检测实际的行尾字符）

您需要修复Windows ASCII到EBCDIC转换器，才能生成固定长度的记录

唯一的另一种选择是在大型机上使用REXX脚本，但这仍然需要能够区分实际的行尾标记和二进制数据中的该标记之间的差异

您可以通过以下事实判断压缩十进制的存在：它由BCD Nybles组成，最后一个是0xC或0xD，但这也可能导致误报或否定

我的建议是：当您将ASCII转换为EBCDIC时，同时将行填充到所需的记录长度

我想提出的另一点是，如果您只想查看大型机上的文件（而不是从任何需要EBCDIC的代码中使用它们），ISPF编辑器包括一些新命令（如果我没记错的话，从z/OS 1.9开始）

---

源ASCII

将数据显示为ASCII而不是EBCDIC。此外，

LF

命令允许您在FB成员中按摩ASCII流，以正确修复行结束。

我正在尝试以ebcdic类型上载文件。我试着用二进制或I型上传它，但问题是它不再包含任何新行。数据集应每行包含一行新行，但当我使用ebcdic类型上载数据时，会出现一些不必要的新行。您的数据在使用二进制（图像）上载时会发生更改吗？除非你的服务器不支持它（这不是强制性的），否则我看不出它是如何产生的。当我使用ebcdic类型上传它时，数据很好，除了不必要的新行或cr/lf。当我使用二进制上传时，数据不再包含cr/lf。服务器确实支持二进制上传。我尝试使用二进制上传，并将文件转换为ascii和ebcdic格式。使用ascii转换时，使用二进制类型上载后，数据不可读，而使用ebcdic时，数据可读，但不包含cr/lfs。您确定转换程序的操作正确吗？如果windows文本文件中的0x0D 0x0A序列是输入中的纯二进制数据（应转换为0x0D 0x25），则其转换方式应与新行（0x15）不同