On Fri, 19 Sep 2008, Hughes, Jim wrote: > Time out. Dog on the field. > > The RFC for ASCII transfer states all ASCII transfers are put on the > wire in ASCII text and carriage return/line feed are record delimiters. > Don't blame Z/VM if the sending system is not creating proper syntax. > > Carriage return/Line Feed is the proper delimiter. > > With that said, I took Roger Deschner's advice a long time ago. All my > transfers into Z/VM are binary. I get to chose the translate table as > well as deal with 0d0a or 0a delimiters. It is done in a pretty simple > pipeline. > > ____________________________ > Jim Hughes > 603-271-5586
I've had this same problem on z/OS. In our case, what happened is the file on UNIX had only a LF (as is normal on UNIX). The person who transferred the file to Windows did it incorrectly (like a BINary transfer). This had the file end up on Windows with only an LF instead of a CRLF. The standard Windows FTP client does not recognize a single LF as an end-of-line and so transfers it as "data" instead of making it a CRLF as specified in the RFC. Oh, another possibility is that the UNIX system running "vsftpd" as its FTP server. The author of this ftp server does not think that going according to the RFC is required. He disables what he calls "ASCII munging" (translating LF to CRLF on the wire for an ASCII transfer). This can be fixed by editing the vsftpd.conf file, normally in /etc/vsftpd, to include the lines: ascii_upload_enable=YES ascii_download_enable=YES The actual error is in the transfer from UNIX to Windows. That is where the "corruption" is occurring because the file ends up on Windows with a non-Windows compliant end-of-line indicator. IIRC, the original file is coming from a system not under the OP's control. -- Maranatha! John McKown
