Re: ftp_get local file question

[Scott Klement <klemscot@xxxxxxxxxxxx>]

Sender: Scott Klement <klemscot@xxxxxxxxxxxx>


comments in-line.

On Tue, 5 Nov 2002, Richard B Baird wrote:
>
> maybe i can help.   can you give me just a little direction (i.e. which of
> your apis, and where I should look to 'sniff' the ibm ftp server perhaps?
>

What does this have to do with the IBM FTP server?!  I didn't even realize
it was part of the issue.

If you have an FTP client that works the way you want it to, then sniff
the network connection.   A sniffer is software that reads every single
packet that's travelling over a network, and displays them to a user.
This is very useful for troubleshooting network software, such as FTP.

The network sniffer that I use is called 'ethereal', you can get it at
http://www.ethereal.com/

What I will do with a problem like this is that I will use the sniffer
to see exactly what data is being sent/received by the software that
works, and then the software that has problems, and compare.

Here's instructions to sniff a session:

    1) Start ethereal
    2) click "Capture" / "Start" / "Ok"
    3) Log on to your iSeries and do the FTP.
    4) When done, go back into ethereal, and click "Stop"
    5) Assuming that all went well, Ethereal should display a list
          of packets that went across the LAN.  Some of them should
          be packets from your iSeries to the FTP server...
          Choose one of those, right click it, and select
          "Follow TCP Stream"
    6) A window opens showing the exact conversation that took
          place.  It should show EXACTLY what was sent to the
          FTP server and received...  (including passwords, etc)

So, now that you've got the exact details, you can compare them and see
what the difference is.


>
> I'm not flush with time, but I really want to get this thing working, so
> maybe i can do the legwork for you.
>

Ummm... you mean do the legwork for yourself.  It's not my job.  I'm just
trying to help YOU.    FTPAPI works absolutely flawlessly for what I use
it for.   It's never failed in the 3 years I've been using it.

>
> plus, i'm having a conversion problem.  i'm getting junk when I get a file
> using the ftp_apis if I do the transfer manually (ibm client), it works
> fine.
>

Then use IBM's client.  I'm getting more than a little tired of hearing
about how much better it is than mine.


> here are the manual commands vs. the apis that I'm using and the messages I
> get in reply:
>
> manually - after login...
>
> > sendpa 0
>   SENDPASV is off.
> > locsite namefmt 1
>   Client NAMEFMT is 1.
> > cd "'FASKNS01'"
>   250 "FASKNS01." is the working directory name prefix.
> > get TSP.FF01.P0SPDOU4.IASKNS.G0002V00 /http/occ/clearedchecks.txt
> 200 Port request OK.
> 125 Sending data set FASKNS01.TSP.FF01.P0SPDOU4.IASKNS.G0002V00 FIXrecfm 80
> 250 Transfer completed successfully.
>  14022 bytes transferred in 2.829 seconds. Transfer rate 4.956 KB/sec.
> quit

There's absolutely no information here about translation.  So, that's
not especially helpful to me.

>
> This works great.  file is in ascii, and is readable.
>
> when I use the ftpapis,
> in order - after login:
>
> ftp_passiv(0)

*** should be ftp_passiv(*OFF), tho I guess ftp_passiv('0') would also
    work.   ftp_passiv(0) wouldn't compile, tho.

> ftp_chdir(ftp:'FASKNS01')
> ftp_get(ftp:TSP.FF01.P0SPDOU4.IASKNS.G0002V00:/http/occ/clearedchecks.txt)

*** missing quotes.

> ftp_quit(ftp)
>
> here is what is in the joblog:
> > CWD 'FASKNS01'
> 250 "FASKNS01." is the working directory name prefix.
> > SIZE TSP.FF01.P0SPDOU4.IASKNS.G0002V00
> 501 command aborted -- FTP server not configured for SIZE
> > TYPE A
> 200 Representation type is Ascii NonPrint
> > PORT 205,243,79,227,234,64
> 200 Port request OK.
> > RETR TSP.FF01.P0SPDOU4.IASKNS.G0002V00
> 125 Sending data set FASKNS01.TSP.FF01.P0SPDOU4.IASKNS.G0002V00 FIXrecfm 80
> 250 Transfer completed successfully.
> > QUIT
> 221 Quit command received. Goodbye.
>
> and I get junk.

Okay.  So with FTPAPI you're using Ascii NonPrint mode.   That means that
the server should be converting the data to ASCII and putting CRLF at
the end of each line.

Of course, all you tell me about the result is that it's 'junk'.  The
code page that's assigned to the file would be nice, and how you're
viewing it.   The hex values of the bytes that you think are 'junk' and
what they SHOULD be would be rather useful.

>
> I've also tried inserting both ftp_binary(1) and ftp_binary(0), before the
> ftp_passiv() function.  the only difference in the job logs for these tries
> is:
> > TYPE I
> 200 Representation type is Image

TYPE I is binary mode (also called 'Image' mode)  TYPE A is ASCII mode.
Isn't this what you expected?


-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------