Scott,
thanks for your excellent explanation of why it didn't work.
So if I understand correctly, the local path always needs to be in
/qsys.lib format, and the remote path can be LIB/FILE if I use name format
0.
I'll subscribe to the FTPAPI list right away.
Thanks,
Peter Colpaert
Application Developer
PLI - IT - Kontich, Belgium
-----
Yoda of Borg are we. Futile is resistance, assimilated will you be.
-----
Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
12/12/2007 14:38
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
To
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
cc
Subject
Re: FTPAPI question
Peter,
FTPAPI only understands IFS naming. It has no notion of the traditional
naming format.
The FTP_NamFmt() API changes the SERVER's name format, but doesn't
change the client's naming format (i.e. it doesn't change FTPAPI's
format.)
so you could potentially do
FTP_NamFmt(connection: 0);
FTP_Get(connection: 'LIB/FILE': '/QSYS.LIB/LIB.LIB/FILE.FILE');
In that case, you've told the server to use naming format 0, so you can
request an object named 'LIB/FILE'. However, to save it on the client
side (where FTPAPI runs) you have to specify the IFS naming ("namefmt 1").
Why didn't I support both naming formats? Because it's more work. It
would've required extra code -- and I didn't see the point in adding the
extra code, since IFS naming provides access to everything. Adding the
other naming format wouldn't have provided any additional capability.
Also, "namefmt" is NOT a standard part of the FTP protocol. It's an
extension that only exists on OS/400. All other systems use
hierarchical naming, much like "namefmt 1".
Having said that, I may end up adding support for namefmt 0 some day in
the future. I personally don't need it, but it seems like everyone else
wants it.
Also, I have a mailing list set up explicitly for FTPAPI and HTTPAPI.
We'd love to see you there.
http://www.scottklement.com/ftpapi/ftpapilist.html
midrange.com
