Re: Problems with FTPAPI between two iSeries'

[Scott Klement <klemscot@xxxxxxxxxxxx>]

Charles,

One difference between FTPAPI and IBM's client is how they deal with 
downloading to files that don't already exist.

IBM's client will download the entire file to a temporary stream file in 
the IFS.  It will then scan the entire stream file checking to see which 
line has the longest record length.  It will create a new PF with that 
longest record length, and copy the FTP data to that newly created file.

Obviously, there's a fair amount of work, and a fair amount of code 
involved in doing that.  When I wrote FTPAPI (10 years ago now?) I 
didn't want to go through all of that, since I figured I'd make sure 
that any file that's supposed to be a database file already exists 
before downloading it.  To me, that's a no brainer.

So, instead of downloading the data and analyzing it like IBM's tool 
does, it just assumes that any un-created PF is supposed to be 1024 
bytes in length, and just does a CRTPF to make a flat file with a 1024 
record length.

If you want to download the file with all of the file header data 
including, create a save file and transfer that.  (This applies to both 
IBM's client and FTPAPI).

If you want to just download the data, but keep the same record length, 
pre-create an empty PF containing the appropriate record length so that 
FTPAPI doesn't have to create the file for you.

Based on your description, what I think is happening...   I think you've 
defined the file with a short record length (13 bytes) and you're 
downloading it into a file created at 1024 bytes by FTPAPI.  It only 
ends up as 2 records in your file because FTPAPI is downloading 78 
records from teh source computer and putting them all into 1 record in 
your 1024 byte record length file. (because 1024 / 13 = 78).  So if your 
source file has between 79 - 156 records, it'd end up with 2 records in 
the destination file.

Using ASCII vs BINARY would shift the data a little bit, since ASCII 
mode will trim trailing blanks, whereas binary won't.

That's my best guess at this point.  Again, try pre-creating an empty 
file (to provide the correct format) before downloading the file, and 
you should be fine. (at least, it works for me.)


Wilt, Charles wrote:
>    All,
 >
>    I've used FTPAPI a few times to send files from the iSeries to a
>    non-iSeries server with no problems.  (Thanks Scott!)
> 
>    However, now I'm trying to pull back a file from one iSeries to
>    another, directly to and from the PF with the data.
> 
>    The files are simple, 3 fields, all character, only 13 bytes total.
> 
>    I confirmed that both files has the same format.
> 
>    But I only get two records in the destination file when there are 560
>    in the source file.
> 
>    I've tried ASCII mode and even binary since I've been able to use the
>    FTP client built into OS/400 to transfer data between to matching
>    physicals in binary mode.
> 
>    Interestingly enough, the two records I get are different, depending
>    on rather ASCII or BIN is used.
> 
>    The first record is the same and looks good, but the second record is
>    different.  I'm not sure but I think the 2nd record I get in the
>    destination file is corrupted and doesn't match anything from the
>    source.
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------