× 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.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.