FTP timing out?

[EdgarZamora]

Local node:
OpenVMS Alpha 7.3-2
HP TCPIP 5.4 ECO 4

Remote node:
OpenVMS Alpha 7.3-2
HP TCPIP 5.4 ECO 6

My large file transfers (I have tried using 4 different files countless times) are timing out (I think) after around 1 hour and 15 minutes (Accounting records show they are all being killed by SYS$DELPRC at around the 1:15:01 mark) with the following error message:

%TCPIP-E-FTP_SEND, cannot send on socket
-SYSTEM-F-LINKDISCON, network partner disconnected logical link
%TCPIP-E-FTP_NETERR, I/O error on network device
-SYSTEM-F-CONNECFAIL, connect to network object timed-out or failed

Slightly smaller transfers that finish within 75 minutes are ok. I can't for the life of me figure out what's timing me out (I could also be exceeeding some sort of quota but I've been watching the remote process and quotas don't seem to be the problem)

There are no "idle job killers" or anything remotely similar running on the remote node. The remote node is an idle system.

Please see attachment for some more details.

Hoff's friends, the network guys, claim they don't have any timers that would kill my transfer. I also believe it's not a network problem because I've successfully ftp'd same files to a remote IBM AIX host located in the same remote datacenter, and exceeding the 1:15:00 mark).

I've checked available patches and didn't see anything relevant. I applied ECO 6 onto the remote node but that didn't help.

I will be trying other things, like transferring to other nodes, going the reverse way etc., but in the meantime I'd appreciate any suggestions.

[EdgarZamora]

I apologize to everyone. It looks like a network problem. In double-checking the logs, the successful file transfer to the IBM AIX host came in under the 1:15:00 mark. Using a larger file, the transfer to the remote IBM host failed at the 75 minute mark, too.

To eliminaate the local VMS host as the problem, we will now try the transfer from another local, non-VMS node to the remote VMS host.

[Steven Schweda]

I almost posted a "blame the network [guys]"
response, but you sounded _so_ sure. FTP is
unusual in its two-port connection scheme,
and that can confuse some idle-connection
detectors. If you have an HTTP server handy,
you could try that as an alternative. Also,
passive-mode FTP sometimes helps accomodate a
lame idle-connection detector.

Of course, when it takes over an hour to run
each test, it's easy to get annoyed.

[Wim Van den Wyngaert]

Try enabling keepalive on the ftp service. This way you have traffic on the command connection and no network device will kill the connection.

Wim

[labadie_1]

I have seen a similar problem when the routers involved in the transfer had a "bad" parameter.

Can you check all the routers you have from A to B and then from B back to A ?

Is it the same path ?

Do the routers all have the same OS/version (of course, tha famous "network guy" will answer) ?

[Wim Van den Wyngaert]

ucx SET SERVICE FTP/SOCKET_OPTIONS=KEEPALIVE
ucx disable servi ftp
ucx enable servi ftp

Wim

[EdgarZamora]

I turned on the keepalive socket option at the remote end, and the file transfer still failed at 75 minutes. I will turn it on at the local (source) node, too, but I will have to get approval first since it's a production system.

Steven, you're right. I'm way past "annoyed" at each test taking 75 minutes. I spent the entire weekend running tests.

[EdgarZamora]

The problem turned out to be a WAN Accelerator that was accelerating the FTP control path. That has been turned off and only the FTP data path is being accelerated now. Thanks to everyone for their suggestions.