Sorry, me again on this. Who is the client and who the server? If the UNIX system is connecting to the z/OS system, i.e. z/OS is the server and UNIX the client (as in the Subject:), then my comments about vsftpd are useless. They are relevant only if vsftpd is the server on the UNIX system.
Have you considered transferring the files into a z/OS UNIX file instead of a legacy dataset? If you do, then you can "post process" the files with a rather simple "tr" command. tr '\45' '\25' <input.file >input.file.fixed This translates octal 45 (x'25') to octal 25 (x'15'). Note that you must use separate input and output files. If you have Dovetailed Technologies dataset pipes, you could do: tr '\45' '\25' <input.file | todsn "//'MVS.OUTPUT.FILE'" Or you could use the "cp" command. tr '\45' '\25' <input.file | cp /dev/fd/0 "//'MVS.OUTPUT.FILE'" If MVS.OUTPUT.FILE does not exist, then you'll likely need to use other parameters to specify things like the space requirements, LRECL, RECFM, etc. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Bri P > Sent: Monday, July 21, 2008 8:33 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: FTP with LF instead of CRLF from a Unix client > > Hi folks > > We have a Unix trading partner who's sending a text file in > with end of line terminators of only Line Feed (LF - x'0A' > ASCII) instead of Carriage Return/Line Feed (CRLF - x'0D0A' ASCII). > > As a result the line ends are not being recognised by our > z/OS 1.7 FTP server and the LFs are going through as data for > one line as will fit the entire length of the LRECL, and > getting converted to x'25' as part of the ASCII-EBCDIC conversion. > > We've had similar problems before but in the other direction, > with us sending CRLFs and the receiver complaining about it > and insisting that WE fix it(!) which we've always done, > despite me citing RFC959, by doing our own formatting and > EBCDIC to ASCII translation then sending the whole lot as > binary.. although I do know about the SBSENDEOL enhancements > in CS 1.7. > > Trouble is, I can't see how I can affect anything in this > case of it coming in like this; that is, unless the user gets > the offending Unix version changed, which I can't see ever happening. > > Despite IBM's technically correct citing of RFC959, and I do > tend to agree with them, in practice however their stance on > it is becoming a bit of a pain when other platforms can > 'accept' such transfers (although even Windows doesn't quite > handle it properly). It's about to get escalated between our > two companies so I need to find a resolution or workaround somehow. > > Has anyone experienced this also, and if so, what did you do about it? > > Thanks in advance > > Brian > > > ----------------------------------------- > Email sent from www.virginmedia.com/email > Virus-checked using McAfee(R) Software and scanned for spam > > ---------------------------------------------------------------------- > 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 > > ---------------------------------------------------------------------- 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
