RE: Problems with FTPAPI between two iSeries'

["Wilt, Charles" <WiltC@xxxxxxxxxx>]

Scott,

Thanks for the reply.  Actually, the PF did already exist.  The problem turned out that I had an older
version of FTPAPI that had a bug in it.

After posting my original message, I found one with a similar problem in the archives, which lead to
the bug being identified and fixed.  Once I downloaded the latest version, everything worked great.

Sorry for the false alarm.

Charles


> -----Original Message-----
> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx 
> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Scott Klement
> Sent: Wednesday, July 18, 2007 2:20 PM
> To: HTTPAPI and FTPAPI Projects
> Subject: Re: Problems with FTPAPI between two iSeries'
> 
> 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
> --------------------------------------------------------------
> ---------
> 
> 

This e-mail transmission contains information that is intended to be confidential and privileged.  If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful.  Please reply to the message immediately by informing the sender that the message was misdirected.  After replying, please delete and otherwise erase it and any attachments from your computer system.  Your assistance in correcting this error is appreciated.
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------