Hung Ultrix LAT sessions?

[George Robbins]

In article <1990Oct30.195838.16943 at watcgl.waterloo.edu> idallen at watcgl.waterloo.edu (Ian! D. Allen [CGL]) writes:
> Ever see the situation where you get disconnected from an Ultrix LAT
> session, try to resume it without success, say "connect" to start over,
> get assigned a different LAT pty and have to log in again, only to
> notice your old session still using the other LAT pty, with no way to
> get connected to it?  Efforts to echo to (or read from) the other LAT pty
> hang?  Then you kill your shell on that LAT pty, and it doesn't die until
> you again go back to the DS200 server, connect (and this time you get
> your old session LAT pty), and see a flood of waiting output, including
> your echo commands, then the shell goes away and the session disconnects?

Uh, no...

The only "problem" we have with LAT's is that when a session has been
"disconnected" either by user command, or more often by the user turning
off their system for the evening, that you can end up with processes
that are hung in "output wait" conditions.  After killing them with a
SIGHUP signal, they go eventually go away.

I can't think of any problems when you couldn't resume (or forward)
a session, though sometimes it gets confusing if you pop back into
a editor or other perverse context when you expected a shell...

> Obviously the LAT session is disconnected from the DS200, but Ultrix is
> trying to flush output through the nonexistent server session and
> hanging.  The pty is marked as "in use", so you can't re-connect to
> it.  Some kind of killing of the shell (or maybe the TIOCSTI of a break
> character I tried) tells Ultrix the pty is free for re-use even though
> it still has all that queued up output, so you can now connect to it
> and get deluged with queued up output before being disconnected again.

It's not disconnected until either the session is terminated at the
server end (try disconnect) or terminated at the Ultrix end, perhaps after
Ultrix decides it doesn't really have to output that buffer after all.

> The initial fun I had with the flexibility of LAT is rapidly fading
> into the depression of realizing the stuff doesn't really work.

While I'm no great LAT proponet, we use it fairly extensively, several
hundred terminal server lines, and it seems rugged and causes no real
problems.  Create a few extra LAT pseudo-terminal lines and don't worry
too much about that particular micro-detail.
-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr at cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)