This is why I do everything in binary mode. I have a PIPE to deblock it and translate to EBCIDIC.
Happiness reigns. ____________________________ Jim Hughes 603-271-5586 "Its kind of fun to do the impossible." (Walt Disney) =>-----Original Message----- =>From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On =>Behalf Of John McKown =>Sent: Friday, September 19, 2008 4:43 PM =>To: [email protected] =>Subject: Re: Question about FTP to z/VM => =>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
