Robert Rather than exercising "trial and error" with FTP parameters it is always possible simply to follow up on the message offered.
In this case it was EZA2589E. Using LookAt! I found the explanation of EZA2589E. Here the universal advice is to note the "operation", in your case "Waiting for Reply", and seek out "A complete description of each operation's relevant client timers and recommended steps for diagnosis can be found in the section on diagnosing FTP transfer failures with EZA2589E in z/OS Communications Server: IP Diagnosis Guide" which I did. <quote> 3.8.2.9.1 Values and explanations for operation in EZA2589E This section lists and describes the values for operation in EZA2589E. ... Waiting for reply Timer INACTTIME Explanation The FTP client is waiting for an expected reply from the FTP server on the control connection. The timer has expired, or the user has interrupted the FTP client before a reply was received. The reply from the FTP server tells the FTP client whether the previous command was successful or not. When a reply is not received, the FTP client must assume that the command was not successful. User Response INACTTIME could be increased to allow the FTP server more time to reply. If the failure recurs, contact the system programmer. System Programmer Response For long running jobs, firewalls might time out the control connection due to inactivity. FTPKEEPALIVE can be coded in FTP.DATA to cause the TCP layer to send KeepAlive packets on the control connection. The firewalls can also be configured with longer inactive times. Use a packet trace to determine if the replies arrive at the FTP client. If the packet trace does not show the FTP reply, determine where the reply is being rejected. Otherwise, contact the IBM Support Center to investigate the packet trace. </quote> Notice how precisely the timer relevant to the "Waiting for reply" "operation" has been identified. It wasn't quite clear where Kevin Clark's TIMEOUT parameter should be applied but you seem to have worked it out anyway. It appears to be a command parameter. In which case it sets the value as a blanket timeout for all of the following parameters: MYOPENTIME, DCONNTIME, CCONNTIME, INACTTIME and DATACTTIME as can be discovered by checking the section "FTP command -- Entering the FTP environment" in Chapter 3, "File Transfer Protocol (FTP)" in Communications Server IP User's Guide and Commands. As you can see, INACTTIME, the parameter you actually needed to "fix", is included. I happened to notice something else which might have been handy as a way of stopping any timeout anywhere, namely TIMEOUT x as explained by this note: "Result: If the value is not a number, all Timeout values are set to 0.". A Timeout value of "0" means there is no timeout. As it was, 12 minutes (= 720 seconds) appears to have been sufficient where 5 minutes (= 300 seconds) was not. Regarding FTPKEEPALIVE: as you know IBM doesn't change parameters once they have been established - as a general rule. Thus FTPKEEPALIVE probably defaults to "off" because, at the time a value was decided on, it was more important to minimise traffic and processing than to assure that the client- server connection was in place. Now such a consideration might seem ridiculous but back in the early '90s or before, it was more important - I guess! - Ha! - after putting all that together, I see you had researched sufficiently to discover that INACTTIME *was* the culprit - I'll leave all the above as possibly useful material for the archive. So all that's relevant for you here is the observation that you needed a value between 5 and 12 minutes - very odd! - and that you could have switched off timeouts altogether - and my guess about why FTPKEEPALIVE defaults to "off". And, possibly for everyone else, *how* you managed to discover that INACTTIME was the culprit. - And another thing: Here is what the Communications server IP Configuration Reference says about INACTTIME: <quote> INACTTIME (FTP client) statement Use the INACTTIME statement to specify the amount of time the FTP client waits for an expected response from the server, on either the control or the data connection, before closing the session. Data transfer times that exceed this value does not cause session termination unless the time between data packet arrivals exceeds this value. </quote> Did you notice "on either the control or the data connection"? Could it be that, just because all sorts of wonderful things are happening on the *data* connection, the *client* connection is another matter entirely and there is total silence? Is it possible that, if the *data* connection is busy for longer that the INACTTIME value, it's goodbye to the *client* connection? Would it be good practice when transferring large volumes on the *data* connection lasting indeterminate long periods, to set INACTTIME 0 for the benefit of the *client* connection? Reviewing the replies yet again, CWCID I see that Dennis Roach was tring to tell us all precisely that the problem was the *client* connection - perhaps with insufficient emphasis - and with the "firewall" red herring thrown in! Chris Mason On Fri, 20 Mar 2009 15:10:45 -0500, Johnston, Robert E <[email protected]> wrote: >I am trying to FTP about 407MB from an external server (CA ESD) to z/OS 1.7, without luck so far. While I continue to mess with this, I'd like to get some feedback about what I've done so far. > >Initial FTP DATA was: >CHKPTINT 0 >DATATIMEOUT 300 >DCONNTIME 120 >FTPKEEPALIVE 0 >INACTIVE 300 > >Has evolved to: >CHKPTINT 0 >DATACTTIME 240 >DATATIMEOUT 300 >DCONNTIME 120 >FTPKEEPALIVE 300 >INACTIVE 300 >INACTTIME 300 > >The last FTP job ended: >16:07:42(000011C0.1) SC3283 receive_data: entered >16:07:42(000011C0.1) MR5735 progressReport: entered >16:07:42(000011C0.1) MF1671 seq_write_file: entered >16:07:42(000011C0.1) SC3283 receive_data: entered >16:07:42(000011C0.1) MF0581 seq_close_file: entered >16:07:42(000011C0.1) MF0660 seq_close_file: file closed >16:07:42(000011C0.1) SC2329 dataClose: entered >16:07:42(000011C0.1) SC2887 getReply: entered >16:07:42(000011C0.1) SC3731 getNextReply: entered with waitForData = TRUE >EZA2589E Connection to server interrupted or timed out. Waiting for reply >EZA1721W Server not responding, closing connection. >16:09:42(000011C0.-1) CU2258 write_smf_record: entered with type 16. > >I know I haven't given much to go on. I ran the same job with no changes and got elapsed times of 33, 8, and 46 minutes. > >It bothers me that I am still getting some kind of timeout after 2 minutes when most of the timers/intervals have been changed to more than 2 minutes (there sure are a lot of timers...). Things I am wondering are... > >Do the times above look reasonable or should I put them back? > >Why doesn't FTPKEEPALIVE default to "on" if it is a good thing? > >If the EZA2589E "Waiting for reply" is covered by the INACTTIME timer, why did it not wait for 5 minutes? > >I'm looking at doing a packet trace next but I am not very familiar with it so it will take me a while. I'll be grateful for any crumbs tossed this way. > >Thanks and have a good weekend, >Robert Johnston >UAMS - Little Rock ---------------------------------------------------------------------- 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
