> -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[email protected]] On Behalf Of Lizette Koehler > Sent: Monday, October 24, 2011 3:10 PM > To: [email protected] > Subject: CRLF in Unix being translated on Mainframe to x'25' > > A programmer I am working with is getting a file from Unix > which will be sent to the mainframe. This will be using FTP. > > The process is we receive the file from the Unix system and > it is placed on a Windows 2008 server. > > Then from the Windows 2008 it is going to be FTP'd to the mainframe. > > Is there a way to keep the CRLF command at the end of each > line? And will the mainframe recognize it as a newline? > > What we really want is the UNIX file to be individual (FB > Lrecl 946) going into the mainframe. > > It seems the Unix CRLF is x'0A' whereas the mainframe is x'25' > > > Thanks for any advice > > Lizette
On most ASCII UNIX system, the end-of-line character is a single LF (LineFeed) or 0x0A. On Windows, the normal end-of-line is a 0x0D0A (CRLF or CarriageReturn-LineFeed). On z/OS UNIX, in EBCDIC, the end-of-line character is the NL (NewLine) or 0x15. NOT 0x25. 0x25 is a CarriageReturn. When you create a file on an ASCII UNIX system, the lines end with a 0x0A. If you store this on a "share" where a Windows server can get at it directly and you use a Windows ftp client, the file in the z/OS UNIX system is "hosed up". Just as you have seen, the lines end with a 0x25 whereas they should end with a 0x15. I view this as an error in the Windows ftp client because it demands that text line end with CRLF instead of just LF. What you can do is have your UNIX process add the "extraneous" CR so that the lines end with a CRLF. There is usually a program called "unix2dos" which can do this. If you don't have "unix2dos", it can be done with a "sed" command: "sed -i 's/$/\r/' file.on.windows". At least, this works with GNU's sed. I don't know about others. Some don't expand \r to CR. You can fix the file on z/OS with tr: tr '\045' '\025' <bad.file.from.windows >good.output.file \045 is octal == 0x25. \025 is octal and == 0x15. I can't figure out how to get "tr" to accept hex instead of octal. I hate that UNIX was developed on a PDP-8 (octal machine). All of the above only works if you're ftp'ing into a z/OS UNIX file. Have fun trying to get it to work into a z/OS sequential dataset. I never have. Stupid Windows ... MS-DOS ... CP/M-80! -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * [email protected] * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
