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 "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 Edward M Martin =>Sent: Friday, September 19, 2008 2:48 PM =>To: [email protected] =>Subject: Re: Question about FTP to z/VM => =>Hello Everyone, => =>Thanks for all the suggestions. => =>The base file is created on Unix system. We get tired of talking to the =>OPIEs about their file characteristics. => =>The file really is going to end up on a VSE/ESA system, =>On the VSE system there is a FTP command RECLF which indicates that the =>X'0A' will be end of record condition instead of the x'0D0A'. => =>I am just amazed that the VSE/ESA system can handle the FTP easier than =>z/VM. => =>So I am getting that z/VM FTP can not handle a file without a CRLF from =>Unix and get it in a readable format?!? => =>The file comes up but is one record of 11919 bytes. => =>Ed Martin =>Aultman Health Foundation =>330-588-4723 =>ext 40441 => =>-----Original Message----- =>From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On =>Behalf Of John McKown =>Sent: Friday, September 19, 2008 2:16 PM =>To: [email protected] =>Subject: Re: Question about FTP to z/VM => =>On Fri, 19 Sep 2008, Edward M Martin wrote: => =>> =>> =>> Hello Everyone, =>> =>> I have a UNIX file that is not using x'0D0A' to delimit the file. =>> =>> It is a print file (I believe) that only uses x'0A'. =>> What is the site command to z/VM to allow the end of record to be =>> only a x'0A'? =>> =>> On the z/VSE side we have a RECLF command. =>> =>> Thanks, =>> =>> Ed Martin =>> =>> Aultman Health Foundation =>> =>> 330-588-4723 =>> =>> ext 40441 => =>How is the file getting to z/VM? I would assume from some Windows =>system. =>If so, then how is the file getting to the Windows system? The problem =>is =>likely due to the original file being created on UNIX. UNIX delimits a =>text line with a single x'0A' (LF). If the file is FTP'ed to Windows in =>ASCII mode, then the ftp client/server will translate this line ending =>from a single LF to a CRLF that Windows expects. If you FTP in BINary =>mode, then the LF stays an LF. Note that FTP is not sftp. sftp does only => =>does BINary transfers. => =>Possible solutions: => =>1) on the UNIX system, before sending to Windows, use the "unix2dos" =>command to change the LF to a CRLF. => =>2) on the Windows system, edit the file using Wordpad or WORD and save =>it =>as a text file with the CRLF endings. If you have Cygwin on your Windows => =>machine, there is a "unix2dos" command which you can use. => =>=== => =>I don't have a z/VM system. When this occurs on z/OS, the file ends up =>with x'25' where the end of record should occur. What I can do at this =>point is put the file to a z/OS UNIX file and issue the command: => =>tr '\45' '\25' <bad.file >good.file => =>This translates the LF (x'25' or octal 45) to a z/OS NEL (x'15' or octal => =>25). I can then copy the file from z/OS UNIX to a z/OS legacy dataset. => =>I don't know if the above is possible with z/VM or not. => =>-- =>Q: What do theoretical physicists drink beer from? =>A: Ein Stein. => =>Maranatha! =>John McKown
