File transfered from WIN to z/OS lost CRLF identifier

A discussion of Co:Z sftp, a port of OpenSSH sftp for z/OS
Post Reply
biggrund
Posts: 2
Joined: Thu Apr 15, 2021 5:34 am

File transfered from WIN to z/OS lost CRLF identifier

Post by biggrund » Thu Apr 15, 2021 9:35 am

Hello Dovetailed,

I am trying to transfer a file from Win to MF. This file has format Non-ISO extended-ASCII text, with CRLF, NEL line terminators.
The original file has CRLF identifier "0D0A" in HEX. As we have succesfully transfered the file, it has lost CRLF. Doesnt matter what parameter we specify in "linerule". Do you have any idea what to specify to keep he original CRLF (0D0A)?

Thank you very much for your help.

Pavel

We use this parameters:
lzopts="mode=text,linerule=(0D0A),servercp=IBM-1047"

The file should looks like this (in HEX):
****** ******************************************************* Top of Data ********
000001 HD:21 20210415 0000800 0001988 0000100 5000001 0000000 @@@@@@@@@@@@@@@@@@@@
4433323333333323333333233333332333333323333333233333330044444444444444444444
84A210202104150000080000001988000001000500000100000000DA00000000000000000000
-----------------------------------------------------------------------------------

The file transfered to MF (in HEX):
****** ******************************************************* Top of Data ***********
000001 HD:11 20210414 0000800 0000497 0000100 0000596 0000000@@@@@@@@@@@@@@@@@@@@@@@@@
4433323333333323333333233333332333333323333333233333334444444444444444444444444
84A1102021041400000800000004970000010000000596000000000000000000000000000000000
--------------------------------------------------------------------------------------

dovetail
Site Admin
Posts: 1978
Joined: Thu Jul 29, 2004 12:12 pm

Re: File transfered from WIN to z/OS lost CRLF identifier

Post by dovetail » Wed Apr 21, 2021 9:25 am

First, it's important that you provide the Co:Z SFTP messages from the transfer. These are available in either the job log (for the Co:Z SFTP client), or in the Co:Z SFTP server log.

From what you have provided (which may not be what is used):
lzopts="mode=text,linerule=(0D0A),servercp=IBM-1047"

means you are doing a text mode transfer where the remote and local codepages are both IBM-1047 (Latin-1 EBCDIC). The stream of data is being broken into records wherever a "0D0A" is found. This happens to be the sequence for CR LF in both ASCII and EBCDIC. Since the z/OS and remote codepage are the same, translation will not be done on the ASCII data.

You also don't say what the record format of the data set is. If the records are fixed length, they will be padded with spaces (in IBM-1047).

This explains the results that you are seeing.

I'm not sure exactly what you want to happen. Your explanation of "the file should look like this" doesn't really make sense:

- Does the data on the server have X'40' (EBCDIC spaces)?

- Do you want records broken at ASCII CRLF? (If you want to treat ASCII CRLF as a line terminator, then this will be removed when the data set record is created.)

- Do you really want the data set to be loaded with ASCII as you have shown?

If you wanted create a data set with ASCII records, you could do this:

lzopts="mode=text,servercp=ISO8859-1,clientcp=ISO8859-1" # default is linerule=flexible

This would result in records being broken at ASCII CRLF, and padded (if necessary) with ASCII blanks (x'20').

If you wanted the ASCII data converted to EBCDIC:

lzopts="mode=text,servercp=ISO8859-1,clientcp=IBM-1047"

these codepages are the defaults with mode=text.

Post Reply