File transfer issue with end of line characters

VINAY PALLELA · New User Joined: 28 Jan 2018 Posts: 24 Location: India

Hi,

Please help me, if there is a way to fix the below issue with file transfer end of line character through NAS step in JCL.

Issue: When i place a file from Mainframe to windows folder( Mainframe PS dataset to .TXT file). I see the file is having end of line characters as LF (LINE FEEDER). BIZTALK will pick the file but they are not able to process the file as BIZTALK is expecting end of line as CRLF.

Is there a way to place the file with CRLF end of line with PARM options.

I have gone through the documentation from the below link but did not find the solution.

www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxa500/tsoocopy.htm

Below is the PARM i am using in NAS STEP.

Robert Sample · Posted: Thu Nov 14, 2019 1:50 am

You've got a flawed process. OCOPY works between z/OS Unix System Services and z/OS -- which means line terminators are going to be the Unix standard LF. The standard and usual way to get CRLF line terminators is to use FTP to transfer the data set from z/OS to a Windows file as text (which will use CRLF by default, or it can be specified as one of the FTP options). As long as you stick with OCOPY, you're not going to see Windows line terminators.

steve-myers · Posted: Thu Nov 14, 2019 6:58 am

Mr. Sample is correct. You are not going to see Windoze style line terminals in the regular z/OS data set - which does not use line terminators at all - or in the output file created by the OCOPY command. It will have the EBCDIC version of the Unix style line terminator. Similarly, if you were able to look at the data sent by z/OS FTP to Windoze, you will not see Windoze style line terminator characters as the FTP standard is to send Unix style line terminator characters. The Windoze FTP inserts Windoze style line terminator characters in place of the Unix style line as it buids the Windoze file when it receives the data.

VINAY PALLELA · New User Joined: 28 Jan 2018 Posts: 24 Location: India

Thank you for taking time to look into my query and respond.

I faced same issue in my previous project and learnt that Windows expect CRLF line terminator and UNIX expects LF line terminators. In my tests i found no issue with FTP but is see the issue with OCOPY. I explained this to my project lead, our Mainframe NASPATH is on UNIX directory, it autopads the line terminators as LF in text file. But my lead was insisting to find the solution with OCOPY and he believes definitely there should be a way with OCOPY options.
Cyclone team fixed the issue, cyclone picks the file from Mainframe NASpath(UNIX) and replace the line terminators as needed and placed the file in Windows sever.

I was told there is standard in our project to use NASPATH for internal file transfers and SFTP for file transfers outside Organization.

I got better understanding now and i can speak to my project lead.

Thanks again!

Joerg.Findeisen · Posted: Fri Nov 15, 2019 12:58 am

FTP is more flexible than OCOPY, basically everything can be done. There is even a special setting for CRLF translations but you might have found that already.