Controlling appearance of new lines in IBM mainframe
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 开发者_如何学Python
12345
23456 12346 IBM MAinFrame View12345..23456..12346
or if block length has been reached..
12345..2345
6..12346Thanks
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:
12345
67890
up in binary mode using literal site recfm=vb
, you'll get the following (shown in ISPF editor with hex on
):
000001
3333300333330044444
12345DA67890DA00000
--------------------------
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:
000001 12345
FFFFF44444444
1234500000000
--------------------
000002 67890
FFFFF44444444
6789000000000
--------------------
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.
精彩评论