I have often had a download timeout in the middle. What you need to do
is only get rid of the unnecessary GET commands. You need to retain the
logon, namefmt, lcd, cd, and binary commands.
Chris Bipes
Director of Information Services
CrossCheck, Inc.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jerry Adams
Sent: Monday, April 14, 2008 2:39 PM
To: Midrange-L
Subject: PTF Download from i5
I am trying, for the first time, to download the latest cume for V5R4M0
via an FTP script that is used by a CL program ala:
OVRDBF FILE(INPUT) TOFILE(CROWLIB/QFTPSRC) MBR(PTFS)
FTP RMTSYS('PTF.BOULDER.IBM.COM')
The script itself is:
ANONYMOUS xxxxxxxx
NAMEFMT 1
LCD '/imgclg/CUME'
ascii
cd /ccss/lv1/us60913/b7760913/00533021/c
get ftpSF99540.txt
get ilstSF99540.txt
binary
get SF99540_1.bin
--etc.--
quit
I had to set up a host table entry (CFGTCP #10) for Boulder on our i5.
Submitted the CL to batch Friday before I left and expected everything
to be downloaded into the i5's IFS when I came in this morning.
But only the text files and the first two CD images (out of ten) were
downloaded. The output shows:
get
SF99540_3.bin
227 Entering Passive Mode
(207,25,253,62,185,131)
150 Opening BINARY mode data connection for SF99540_3.bin (675840000
bytes).
Unable to receive data from
TCP/IP.
No response from remote host; all connections closed.
There actually were somewhere around 449mb in the image.
Anyway, I tried the FTP from the web browser. It worked fine (the byte
count agreed with the FTP text file). So I modified the script by
deleting the lines for the images that I had already downloaded. CD
image #4 bombed with the same message in the output report file. The
joblog tells me nothing except that the FTP command executed and,
according to it, finished successfully. But every "get" after the
error shows:
get SF99540_5.bin
You must first open a connection.
Enter an FTP subcommand.
I tried a test whereby the web browser downloaded the CD image to one
IFS sub-filer and the script downloaded the same CD image to a different
sub-folder. The web browser FTP succeeded; the script blew off as
described above.
FWIW, we have a new SonicWall firewall, which seems to conflict with
Download Director; it seems DD keeps trying to open too many connections
at some point. Not really sure what's going on there. But the web
browser FTP goes through the same firewall and works OK (so far).
After talking with a couple of people at COMMON a few weeks ago, the FTP
script + CL program seemed to be a pretty good idea - unattended
download. Seems reasonable and, as I said, the first two CD images
appeared to download fine, but the 3rd and 4th images didn't. I don't
think it's the script since, after the set up, it's just one "get" after
another.
Hopefully I have provided enough information; it's everything I have
been able to find. If anyone has a clue (or a shot in the dark) what to
look for that is causing the download (FTP script+CL version) to bomb
after churning along for many minutes, I sure would appreciate it.
Thanks.
midrange.com
