D. Allen [CGL]" <idallen@watcgl.waterloo.edu> (10/31/90)
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? 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. DS200/MC into DS5400, Ultrix 3.1C with mandatory patch tape applied. The initial fun I had with the flexibility of LAT is rapidly fading into the depression of realizing the stuff doesn't really work. -- -IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada
grr@cbmvax.commodore.com (George Robbins) (11/01/90)
In article <1990Oct30.195838.16943@watcgl.waterloo.edu> idallen@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@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
jmg@cernvax.UUCP (mike gerard) (11/01/90)
In article <1990Oct30.195838.16943@watcgl.waterloo.edu> idallen@watcgl.waterloo.edu (Ian! D. Allen [CGL]) writes: >DS200/MC into DS5400, Ultrix 3.1C with mandatory patch tape applied. Which mandatory patch tape? What patches? At various times I have had patches for Ultrix: some (concerned with LAT) were a disaster for my application, others were useful. -- _ _ o | __ | jmg@cernvax.uucp | | | | _ / \ _ __ _ __ _| jmg@cernvax.bitnet | | | | |_) /_) | __/_) | (___\ | (_/ | J. M. Gerard, Div. DD, CERN, | | |_|_| \_/\___ \__/ \___| (_|_| \_|_ 1211 Geneva 23, Switzerland
D. Allen [CGL]) (11/01/90)
>>DS200/MC into DS5400, Ultrix 3.1C with mandatory patch tape applied. >Which mandatory patch tape? What patches? I don't know. My DEC rep gave me this TK50 with some tar files on it that replaced /bin/csh and some kernel .o files, mostly dealing with LAT. The biggest changes were csh no longer looping and taking all the memory and LAT ports now going into PASSALL mode when Ultrix does "stty raw" (apparently with no way to turn OFF this behaviour!). -- -IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada
D. Allen [CGL]) (11/01/90)
>It's not disconnected until either the session is terminated at the >server end (try disconnect) or terminated at the Ultrix end [...] There were no sessions resumable or disconnectable on the DS200 server. Only the Ultrix end was alive (had processes stuck on it), until I sent a few HUP signals from another terminal and finally did another CONNECT that got me the same stuck pty and let the stuck output flush; then the Ultrix end cleared up. I still haven't managed to get UUCP to come in through the DS200 at 19200bps via our Telebit Trailblazer Plus. It hangs. Use of the modem by real people, not UUCP, works okay. Modems running UUCP at 2400bps work, except they waste a half hour after UUCICO finishes and before the server times out the connection, because the DS200 has no way to say "when you log out of this *session*, also log out of the *server*, drop the line, and hang up the modem". This half hour waste annoys our long-distance UUCP friends and ties up our modems. It's even worse if the session goes away in the middle of a persistent UUCICO transmission -- the session goes away, the server prompt comes back, and UUCICO shouts nonsense at the server with the server echoing it back for hours on end. That really annoyed a long-distance UUCP friend; he doesn't call me any more. Such a simple thing! Log out the port and drop the line when the current sesion ends, just like a normal serial line. Can't be done. Sigh. -- -IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada