Re: Controlling end-of-record on FTP'ed files

["M. Lazarus" <mlazarus@xxxxxxxx>]

Ken,

 One problem w/ the default FTP EOL characters is that there is no control 
over this behavior.  I am FTP'ing the file to a Unix server, but it still 
seems to send the full CR/LF, not just LF.  Also, compounding the problem 
is the I want to use CPYTOIMPF from a regular DB to a flat file, so that I 
can convert to a tab delimited file.  Unfortunately, that command requires 
an EOR delimiter, even when copying to a DB file.  Also, it can only be ONE 
character AND *CRLF is not valid!

 It looks like I'm going to have to use the IFS.  This allows doing the 
CPYTOIMPF, with the proper EOL characters and the conversion to ASCII, so 
when it gets FTP'ed to the Unix server no additional conversion takes place.

 -mark

At 3/23/05 04:35 PM, you wrote:
> Hi Mark -
>
> >   I spoke to IBM about the situation.  Apparently, a decision was made
> > about the "native / QSYS.LIB FTP extensions" that they would always add the
> > CR/LF as the EOR delimiters when going from a QSYS.LIB file to an ASCII (or
> > maybe it's only Unix) system.
>
> IIRC, the standards for FTP ASCII processing require the sending system to 
> convert from its end-of-line/end-of-record format to CR+LF, and the 
> receiving system to convert from CR+LF to its end-of-line/end-of-record format.
>
> So in ASCII mode there is always going to be a CR+LF delimiter.  If the 
> receiving system is Windoze, it will stay as CR+LF.  If it is Linux, Unix, 
> etc., it will be changed to just LF.  If it is a Mac, it will be changed 
> to just CR (I think).
>
> If the receiving system is an iSeries/AS/400, it will depend on what file 
> hierarchy it is going into, etc.
>
> --
> Ken
> http://www.ke9nr.net/
> Opinions expressed are my own and do not necessarily represent the views 
> of my employer or anyone in their right mind.