I once had a problem FTPing a large dump to IBM. It kept timing out, and since I could not list the IBM side, thought it failed and sent it to a new name, which also timed out. I let IBM know and both files were the same size and complete, so that connection seemed to just be there to let me know at the end whether it worked or not. I want to believe it does more than that. Too long ago to remember if this was a mainframe to IBM ftp or a windows to IBM ftp.
I then started using a larger TIMEOUT value in my batch JCL. Not sure what the upper limit is. And these days do lpar to lpar FTP without it. Usually completing in uder 5 minutes. // EXEC PGM=FTP,REGION=2048K, // PARM='ftp.site.name.or.ip.address -v (EXIT TIMEOUT 1200' On Tue, 25 Mar 2008 15:20:05 -0500, McKown, John <[EMAIL PROTECTED]> wrote: > >Well, the firewall theory has bitten the dust. The LAN people have done >a packet trace on each side of the firewall. The results are identical. >no packets are being lost. And I transferred another really huge file to >the "bad" server which took over 4 minutes successfully. [blech] > >Another weirdness: I can ftp the same data to a different Windows server >fine. I can ftp it to a Linux server fine. I can then ftp it from the >Linux server to the "broken" Windows server fine. > >If I convert the data to ASCII on the mainframe and do a "binary" >transfer to the "bad" Windows server, it fails the same way. The ASCII >data on the mainframe, when binary ftp'ed to my Linux server is >identical to ftp'ing the EBCDIC file using the ASCII command on the ftp. >I'm really tired of this problem. > >-- >John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
