× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thanks, Scott,

Another responder got me to look at the actual calls in the FTPAPI modules and it's stated right there... the destination file must be specified in NAMFMT 1 format.
I will change that immediately. I am mystified where the actual data went though, since the Transfer succeeded. My presumption is that my destination specification
was unintelligible to the procedure so it created a file named the same as the source file, but I can't find anything like that on the box.

No matter. I will make the changes needed. Thanks for a great tool, and your response.

Thomas Garvey

On 2/25/2014 9:07 PM, Scott Klement wrote:
Thomas,

Not sure if you know this, but FTPAPI is a completely different code
base than the IBM FTP client. It does not use the IBM client at all...
it's an entirely different tool. (Some people think it's just feeding
'batch' commands to the IBM client, but it is not.)

This is important to understand, because FTPAPI does not have the same
'quirks' as the IBM client. It has it's own, different quirks :-)

Anyway, you can't do something like 'upisavf (replace' in FTPAPI. That
is an IBM quirk... :-) (I've never seen another FTP client that
requires you to append '(replace' like that besides the IBM one.)

Your 'WhereToPut' should be something like:
'/QSYS.LIB/YOURLIB.LIB/UPISAVF.SAVF'


FTPAPI only supports IFS filename notation, like that...

-SK


On 2/25/2014 3:17 PM, Thomas Garvey wrote:
Yes, by manually I mean using the IBM FTP client on the same IBM i where
I am using FTPAPI.

Here are the FTPAPI commands I'm sending...

ftp_logging(ftp: *on);

ftp = ftp_conn('ftpsite.com' : 'username' : 'password' );

DirToUse = 'ftpsite.com/downloads/Spec-Directory/ ';
if ftp_chdir(ftp: DirToUse ) < 0;
Msg = ftp_errorMsg(ftp);
ftp_quit(ftp);
*InLR = *on;
return;
endif;

ftp_binaryMode(ftp: *on);

FileToGet = 'SPECFILE68.bin';
WhereToPut = 'upisavf (replace' ;
if ftp_get(ftp: FileToGet : WhereToPut ) < 0;
Msg = ftp_errorMsg(ftp);
ftp_quit(ftp);
*inlr = *on;
return;
endif;

ftp_quit(ftp);


Here's the commands from the log...
0: FTPAPI version 2.3 released on 2010-05-27
0: 220 ProFTPD 1.3.3g Server (Main FTP Server) [71.18.107.138]
0: > USER username
0: 331 Password required for username
0: > PASS **********
0: 230 User username logged in
0: > CWD ftpsite.com/downloads/Spec-Directory/
0: 250 CWD command successful
0: > TYPE I
0: 200 Type set to I
0: > PORT 192,168,0,5,50,144
0: 200 PORT command successful
0: > RETR SPECFILE68.bin
0: 150 Opening BINARY mode data connection for SPECFILE68.bin (15434496
bytes)
0: 226 Transfer complete
0: > QUIT
0: 221 Goodbye.

The only thing I see different between the 'manual' method and the log
from FTPAPI is I don't see a message about PASV mode being entered. I'm
ignorant of what that might mean, or if it's pertinent.

Thanks for any advice, Scott.

Thomas Garvey


On 2/25/2014 2:53 PM, Scott Klement wrote:
When you say "doing this manually", I assume you mean that you're using
the IBM FTP client instead of FTPAPI.

Can you tell me how to reproduce the problem?


On 2/25/2014 2:45 PM, Thomas Garvey wrote:
Hi,

Using Scott Klement's FTPAPI Service program I am downloading a file
from an ftp site to a save file on our IBM i system. The GET command
succeeds but the receiving save file is empty.
When I do the steps manually, it works. When issued as procedure calls
using FTPAPI the file is empty.

What am I missing?


(Yes, I use the binary command and the (replace on the get command).

Any ideas?

Thomas Garvey




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.