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

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

Billy,

 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.

 The solution is to do a CPYTOIMPF to an IFS file and then FTP that file 
to the remote server.

 -mark

At 3/22/05 05:50 PM, you wrote:

> M. Lazarus wrote:
> >  How can I control the EOR characters on an FTP'ed file?  By default, 
> > when I FTP a (flat) file from the /400 to a Unix box, FTP adds CR/LF to 
> > the end of the record.  Sometimes I only want a CR.
> >  I tried using the STRUCT R subcommand, but that gave me odd results.
> > On a 2 record file, after the first record x'FF01' was appended and after 
> > the last x'FF03'.  Is this supposed to happen?
> >  The flat file was created via CRTPF w/ a record length of 3,000 (plenty 
> > of room to accommodate the data.)  I am populating it via CPYTOIMPF.  I 
> > tried playing w/ the RCDDLM() parm, but that only allows one character 
> > when copying to a database file (as opposed to the IFS.)
>
> Mark, I'm not sure if this will help but here goes:
> We have some processes that FTP back and forth between AS/400's and 
> Unix  boxes, some of the files are ftp'd from the as400's OS/400 file 
> system which is just like you are talking about, i.e. a flat file and some 
> are ftp'd from the root file system.  The FTP from the as/400's either from
> the os/400 file system or the root file system defaults to ASCII transfer 
> mode so the carriage return is stripped of leaving just a LF, below is an 
> example of the 1st 2 rows dumped on the unix box:
>
> dev> od -c DBflatfile.txt
> 0000000   *   *   R   E   P  \t   e   m   p   t   y  \n   *   *   A   R
> 0000020   _   I   N   V   _   B   A   T   C   H  \t   e   m   p   t   y
> 0000040  \n
>
> Now if you change the mode to BINARY before transferring it would keep 
> both the carraige return and line feed since in a binary xfer you want the 
> exact image of what you are transferring.
>
> HTH,
> Billy