控制 IBM 大型机中新线路的出现
所有，
所以我将一个文本文件从 C# 上传到 IBM MVS 大型机。该文件使用 C# 库转换为 ebcdic，并且运行良好，因为我可以读取大型机上的数据。问题是新线路。该文本文件有 10 行数据，在大型机环境中查看时，所有数据都存在。但是没有新行，因为它将文本文件中的每个新行转换为 0D25，即 CRLF。该段在屏幕上显示为 ..。
我不想要十六进制读数为 0D25 的 2 个点，因为我需要它将数据实际放置在文本文件中的下一行上。顺便说一句，该文件在大型机上一次是可变块长度的。在 MVS 上查看上传的文件时，如何实现与文本文件相同的格式？
示例： 文本文件视图
12345
23456
12346
IBM MAinFrame View
12345..23456..12346
或如果已达到块长度..
12345..2345
6..12346
谢谢
All,
So I'm uploading a text file from C# to an IBM MVS mainframe. The file is converted to ebcdic using C# libraries and it works well as I can read the data on the mainframe. The problem is the new lines. The text file has 10 rows of data and while viewing it in the mainframe environment, all data is present. But there are no new lines as it translates each new line from the text file as 0D25, which is CRLF. This segment appears as .. on screen.
I don't want the the 2 dots that have the hex reading of 0D25 because I need it to actually place the data on the next line as it is in the text file. The file is variable block length once on the mainframe btw. How can I achieve the same formatting as the text file while viewing the uploaded file on MVS ?
example:
TEXT FILE VIEW
12345
23456
12346
IBM MAinFrame View
12345..23456..12346
or if block length has been reached..
12345..2345
6..12346
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您在 FTP 传输过程之外进行 ASCII-EBCDIC 转换，我必须假设您正在以二进制模式进行传输（否则转换将再次完成，并且您的数据将会损坏） ）。
如果是这种情况，那么我很确定您也要对行结尾的转换负责。二进制传输不会尝试转换行结尾。在将其发送到主机之前，您需要将行填充到所需的长度并完全删除行结尾。
举例来说，如果您
使用
literal site recfm=vb以二进制模式传输此文件：up，您将得到以下内容（在 ISPF 编辑器中显示，hex on):你可以看到它只是按原样传输字节，包括 CR/LF。如果您在 FTP 中切换到 ASCII 模式并再次上传，您将得到：
这里，字符已被转换为正确的 EBCDIC 代码点，并且行结尾已变为带有 EBCDIC 空格的填充。
我想我向您提出的第一个问题是：“为什么您要在 FTP 之外进行翻译？”
IBM 投入了大量资金来确保它能够接受各种不同的编码并将它们转换为正确的代码页。独立的解决方案不太可能像 IBM 自己的 z/OS 版本一样适用于所有国际化版本的 z/OS。
如果您必须在客户端上进行转换并以二进制模式传输，则必须让客户端同时执行行结束转换和填充，或者在传输后对文件进行后处理，例如使用 REXX 脚本。
如果您不知道目标数据集的属性是什么（例如，如果您要转为 PDS 中的成员），则后一种选择可能是唯一可行的选择。
If you're doing the ASCII-EBCDIC translation outside of the FTP transfer process, I have to assume that you're transferring in binary mode (otherwise the translation would be done again and your data would be bad).
If that is the case, then I'm pretty certain you're responsible yourself for the conversion of line endings as well. Binary transfers will not attempt to convert line endings. You'll need to pad out the lines to the desired lengths and remove the line endings altogether, before sending it up to the host.
By way of example, if you transfer this file:
up in binary mode using
literal site recfm=vb, you'll get the following (shown in ISPF editor withhex on):You can see it's just transferred the bytes as-is, including the CR/LF. If you switch to ASCII mode in FTP and upload again, you get:
Here, the characters have been converted to the right EBCDIC code points and the line endings have been morphed into padding with EBCDIC spaces.
I suppose my first question to you would be: "Why are you doing the translation outside of FTP?"
IBM invests quite a lot of money in ensuring that it will accept all sorts of different encodings and translate them into the correct code page. It's very unlikely that a stand-alone solution will work on all the internationalised versions of z/OS as well as IBM's own.
If you must convert on the client and transfer in binary mode, you'll either have to have the client do the line ending conversion and padding as well or post-process the file after the transfer, such as with a REXX script.
If you don't know what the properties of the target data set will be (such as if you're transferring into a member in a PDS), the latter option may be the only viable one.