FTP PUT/GET Fails to Complete with an interrupted, timed out, or not responding condition.

Resolving The Problem

There are multiple reasons why a timeout can occur.
Be sure the following z/OS FTP client timer (specified in the client FTP.DATA file) default values are set to the defaults or higher:

• CCONNTIME 30
• DATACTTIME 120
• DCONNTIME 120
• INACTTIME 120
• MYOPENTIME 60
• PROGRESS 10

Try increasing the appropriate DATAACTTIME or DATATIMEOUT keyword to allow more time for the data to be sent before FTP times out.

If FTP time-outs continue to occur, following areas will need to be investigated:

• Possible networking delays in data transmission and or improperly configured nodes along the path data is being sent over. Example: Intermediate nodes that are unable to pass jumbo packets. In this case, packet tracing shows that the three-way handshake for the control connection is successful. However, when the first jumbo packet is sent, no ACK is returned and eventually, retransmission mode is entered. For OSA devices where a switch is involved, a trunk might also exist between the OSA and the switch. You must configure this trunk to accept jumbo size frames and configure the MTU size on the physical link to accept these frames, or they will be dropped and FTP will time out with errors similar to those above.
  
  NOTE: An analysis of a packet trace is usually a first step in diagnosing what type of problem is being experienced. Please refer to the FTP Timeouts During Data Transfer for the z/OS FTP Server and FTP Timeouts During Data Transfer for the z/OS FTP Client technical documents for details on how to review an FTP-related packet trace.
• Is the FTP Client/Server getting enough machine cycles to process the data?
  
  NOTE: This may be reflected in the packet trace by the window size going to zero which would inhibit further data transfer until the window opens up. While this is occurring, the appropriate DATAACTTIME/DATATIMEOUT timers will continue to count down and may cause a timeout to occur.

• Issues can also arise when a firewall between the client and the server decides that the Control session is idle and sends a RST to close the control session before the data transfer is complete. For this situation we suggest coding a value for FTPKEEPALIVE in the FTP.DATA file 60 seconds or greater. With a short FTPKEEPALIVE time, a special packet is sent after the time interval, and some firewalls will not allow that, terminating the connection when the keepalive packet is detected. Some firewalls do not allow an idle connection to stay connected for more than a certain period of time. Check with your firewall support as to what the requirements to allow this to work.
• If you have a checkpoint firewall, make sure you have turned off the FTP enforce new line setting in the firewall's configuration. Here are instructions on how to do this: Edit the $FWDIR/lib/base.def to comment out the following line:

Then re-install the security policy.