The FTP idle timeout is likely unrelated to the TCP level keepalives. TCP keepalives will not progress beyond the TCP layer, so FTP above it will still think the FTP control connection is "idle."
So, if it is indeed the case that the IBM system is upset that it hasn't heard anything on the control connection for five minutes, that means one either has to figure-out why the data transfer is taking longer than five minutes, or convince the IBM system to have a longer idle control timeout.
I'm not a VMS guy (just plain networking :) but on the FTP clients I've used, one can use the "idle" command to request a different idle timeout on the control connection. The FTP server retains the last word, but it might be worth a shot.
As for the speed of transfer, might be interesting to check the TCP statistics on the sending side, and receiving side if you can. Look for things like retransmissions and retransmission timeouts. I've no idea how much work it would take to compile under VMS, but "beforeafter" from ftp.cup.hp.com dist/networking/tools/ can be used to subtract one file of network statistics from another (at least the netstat format one finds under HP-UX and linux)
If you can check link-level stats that would be good as well. While transfers to the local VMS systems suggest that the link-level is OK, this boilerplate on duplex may be of interest:
$ cat usenet_replies/duplex
How Autoneg is supposed to work:
When both sides of the link are set to autoneg, they will "negotiate"
the duplex setting and select full duplex if both sides can do
full-duplex.
If one side is hardcoded and not using autoneg, the autoneg process
will "fail" and the side trying to autoneg is required by spec to use
half-duplex mode.
If one side is using half-duplex, and the other is using full-duplex,
sorrow and woe is the usual result.
So, the following table shows what will happen given various settings
on each side:
Auto Half Full
Auto Happiness Lucky Sorrow
Half Lucky Happiness Sorrow
Full Sorrow Sorrow Happiness
Happiness means that there is a good shot of everything going well.
Lucky means that things will likely go well, but not because you did
anything correctly :) Sorrow means that there _will_ be a duplex
mis-match.
When there is a duplex mismatch, on the side running half-duplex you
will see various errors and probably a number of late collisions. On
the side running full-duplex you will see things like FCS errors.
Note that those errors are not necessarily conclusive, they are simply
indicators.
Also, if the IBM system is "far away" - in terms of latency - eg ping times if there was any change in default TCP window/socket buffer sizes with the VMS change that may have affected the transfer speed. One limit to TCP transfer speed is:
WindowSize/RoundTripTime
While the IBM system is likely advertising the same window size as before, perhaps the VMS system is no longer taking full advantage - "WindowSize" here would be the smaller of the receiver's window, the sender's equivalen to the SO_SNDBUF, and the sender's congestion window.
there is no rest for the wicked yet the virtuous have no pillows
