RE: Batch FTP

I attempted to use the SENDPORT command to shut of PASV mode and had no
success, same results as without it.

Regarding the confusing contents of the batch file and it's log, I took some
license to replace out the real path and IP.  I replaced the name of our
server with "server", however did not make the same consistent change in the
log file as well.
Trust the paths are correct, as the real commands work fine when entered
manually one at a time from within an ftp session.  I have adjusted the log
file below to more accurately reflect the resulting commands.

I tried a much smaller path, one level deep from QNTC and got the same
results.

I tried downloading the files into the IFS and the DID load successfully.
It is looking like a security matter between the AS/400 and QNTC, that as of
now is eluding us.  We wanted to use QNTC for its available disk space and
make it a part of some archiving CD burns.  We can leave it in the IFS and
process from there, if need be; or within program control copy it to the
QNTC directory structure.  It appears that this is specifically some
inconsistency between as400 mget and qntc.

This is our first attempt at trying to take advantage of the AS400 ftp
client.  We like the way we can handle things all within program control,
taking advantage of an AS400 scheduled batch job.  The win2K job scheduler
is not to be trusted!   The inconsistency between the running of the
commands manually and in batch, and the amount of time thus far in trying to
figure out where things are unhappy are unfortunate.  Any other
suggestions/ideas would be greatly appreciated.

Thanks again to all for their advice. :o)



Date: Mon, 29 Apr 2002 16:29:23 -0500 (CDT)
From: Scott Klement <klemscot@klements.com>
To: midrange-l@midrange.com
Subject: Re: Batch FTP with Mget
Reply-To: midrange-l@midrange.com


I'm not a big user of NT networking, but...  isn't QNTC the AS/400's way
of writing data to an NT server?

Isn't the first "subdirectory" under QNTC supposed to be the name of an
NT server, and the next "subdirectory" below that supposed to be the name
of the share it's accessing?

You don't actually have an NT server called 'uploads' with a share called
'access_log_20020419.gz' do you?  (I'm not sure you even CAN have a share
name that long, and I bet that's why its calling it 'access_log_20' in the
error msg)

Actually, now that I look closer, your batch FTP script says
'lcd /qntc/server/uploads' but your error message says '/qntc/uploads'.
That's VERY strange.  Or is that a typo?

At any rate, I'd try a normal directory in the IFS, rather than writing
it to an NT server, and see if that helps.   If so, then I'd look more
carefully at what the path should be to get to your NT server.  (Or maybe
FTP from the NT server directly)


On Mon, 29 Apr 2002, Rick Nardone wrote:

> I read through the archive list and could find no reference to this
specific
> problem.  Running V5R1, on the latest cum, and attempting to do an FTP
Mget
> in batch.  The command set listed below works perfectly well when issued
> line by line in an ftp session, but fails in batch.  I checked IBM for
> PTFs/APARs and could find none.  Any information on how to make this
> function would be greatly appreciated.
>
> Basically, the first file in the MGET sequence is downloaded, the
remaining
> files fail with error message "Unable to open or create file".  Note: IP
> address designation in the log has been changed to aaa,bbb,ccc,ddd.
>
> Ftp Script File
> ---------------
> username password
> debug
> namefmt 1
> cd server_logs
> lcd /qntc/server/uploads
> binary
> mget *.gz (replace
> quit
>
>
>
> Sniglet of the ftp log file
> ---------------------------
> Type set to I.
> Enter an FTP subcommand.
> > mget *.gz (replace
> >>> TYPE A
> 200 Type set to A.
> >>> PASV
> 227 Entering Passive Mode (aaa,bbb,ccc,ddd,9,190).
> >>> NLST *.gz
> 150 Opening ASCII mode data connection for file list
> 226 Transfer complete.
> >>> TYPE I
> 200 Type set to I.
> Default file name is access_log_20020418.gz
> >>> PASV
> 227 Entering Passive Mode (aaa,bbb,ccc,ddd,9,191).
> >>> RETR access_log_20020418.gz
> 150 Opening BINARY mode data connection for access_log_20020418.gz
>  bytes).
> 226 Transfer complete.
>  12673 bytes transferred in 0.470 seconds. Transfer rate 26.980 KB
> Default file name is access_log_20020419.gz
> >>> PASV
> 227 Entering Passive Mode (aaa,bbb,ccc,ddd,9,192).
> >>> RETR access_log_20020419.gz
> 150 Opening BINARY mode data connection for access_log_20020419.gz
>  bytes).
> Unable to open or create file /qntc/server/uploads/access_log_20020419.gz
>  receive data.
> >>> ABOR
> 226 Transfer complete.