How to have FTP timeout

[Willem Grooters]

In DCL, I'm using FTP/INPUT= in a subprocess to get a list from a non-VMS remote site to get a listing of files on that system. But FTP seems to ignore connection loss at some point (eg. login at FTP to a (non-VMS) environment) - I've seen that several times - and this causes teh job to stay executing - HIB state.

Is there an way to have FTP timeout, so connection loss will stop FTP after some time?

Willem

[Oswald Knoppers_1]

Hoi Willem,

Maybe you could try to enable tcp keepalive.

$ sysconfig -r inet tcp_keepalive_default=1

Oswald

[Jan van den Ende]

Willem,

If Oswalds solution does not work (but I know nothing in that respect) you COULD easily make your own poor-man's timeout from DCL.
In your , get its processes'PID.
Determine your timeout period, then SPAWN a grand-child supprocess that KILLs its parent PID after .
If the FTP process finishes, it will clear out the suicide subprocess, if timeout is reached, it will be finished.

We used SUICIDE_PARENT.COM for various processes (usually, but not necessarily batchjobs, that we wanted terminated within a certain time (absolute or delta).
It also did MAIL some info to system management whenever it reached the timeout.

hth

Proost.

Have one on me.

jpe

[Hoff · Accepted solution]

Ah, ftp. My absolute favorite tool, and the paragon of design elegance and network security and application stability. Not.

Please try DIRECTORY /FTP here, rather than the ftp utility mode operations.

Definitely look for patches for whatever version this is, too.

[Willem Grooters]

@Hoff: I know, it should be needed in the first place. But DIR/FTP could well do the trick. It'll be harder to test how it reacts on the loss of connection, though...But that's not important if DIR/FTP is more atomic than FTP/INPUT...

Willem

[Hoff]

ignoring that ftp is a horrid and intractable mess, that it is inherently incompatible with modern network designs, and the inevitable exposure of credentials, the DIRECTORY /FTP command is somewhat easier to deal with and easier to trap and easier to debug than is the ftp utility, for definitions of "somewhat" that don't also include "reliable", "secure", "appropriate" nor "good".

Unfortunately, VMS tends not to be as easy to configure for these sorts of alternative file transfers as are other systems, so folks do tend to fall back into the ftp mess.

On the OpenVMS ftp client, confirm TCPIP$FTP_KEEPALIVE is defined. On the OpenVMS ftp daemon, confirm TCPIP> SET SERVICE FTP /SOCKET_OPTIONS=KEEPALIVE is enabled. For this case, check the analogous settings over on the ftp server.

If ftp is the answer, then the question usually needs to be rethought. And no, I'm not a proponent of ftp.

[Jeremy Begg]

Hi Willem,

Have a look at my TIMEOUT program which you can download from

ftp://ftp.vsm.com.au/kits/timeout.zip

It was exactly the situation you encountered which caused me to write TIMEOUT.

Regards,
Jeremy Begg

[Willem Grooters]

@Hoff: Typo. I meant the opposite: FTP shouldn't be used in the first place. I'm well aware of the problems. Security is less of a concern in this environment (local network, restricted access anyway)...

@Jeremy: I'll take a look, but I doubt it can be of use here (it's already a problem to get new, in-house built procedures copies into production...)

@Oswald, Jan, Hoff: Same for your suggestion on KeepAlive: It may do the trick but getting it on the system is a challenge in itself...

[Willem Grooters]

Though not the best, I'll implement DIR/FTP, being the asy way to achieve what's required.