VMS rsh to Tru64

[Howard_24]

I have a DS25 running Openvms 8.2 and when I rsh to a Tru64 machine with a command like ls it works, but when I run a job on the Tru64 (5.1B) machine the job runs okay, but then rsh hangs.

We don't get the acknowledgement that the job completed, but if the jobs completes within 5 minutes we get the acknowledgement.

Does anyone know if there are any parameters that could effect this or has anyone else seen an issue like this before?

Thanks,

Howard

[Hoff]

Introduce a third and preferably unrelated rsh client (eg: Mac OS X) into the mix and try to narrow it down to the OpenVMS (Process MultiNet, HP TCP/IP Services, etc) rsh client or to the Tru64 Unix rsh server.

Alternatively, various of these IP application connections can fail when no I/O passes over the link; there can be a ping or a timeout built into various the IP application protocols. In typical rsh clients, the timeout established with the -t timeout value; there doesn't appear to be a ping or keepalive timer in this case. Check your particular rsh client for details.

And if there is any sort of interactivity, rlogin or ssh may be more useful. And ssh is more useful in terms of its security, too.

Stephen Hoffman
HoffmanLabs LLC

[Steven Schweda]

I routinely rsh interactively into my Tru64
system (V5.1B-4) and see no such time-outs,
but I seldom do "rsh some_slow_command". Do
you get the same effect with an idle shell
session, or just with a some_slow_command?

Knowing nothing, I'd guess that there's some
idle-session-time-out thing working on the
Tru64 side.

[Jim_McKinney]

> I'd guess that there's some idle-session-time-out thing working on the Tru64 side.

... or an intervening firewall may be dropping what it believes is an idle session.

[John Gillings]

Howard,

If you can't find any other clues, I'd try a binary search to determine the exact time period which separates "working" and "not working". Make the job to the equivalent of DCL code:

$ WAIT 'time'
$ WRITE SYS$OUTPUT "finished after ''time'"

Run this, binary chopping the time until you've got it down to less than a 1 second difference. This may help identify where the timeout is defined.

And yes, I've seen this type of thing many times before, usually worked around by implementing some kind of "keepalive" message issued at intervals.