From:	CSBVAX::MRGATE!@KL.SRI.Com,@wiscvm.wisc.edu,@YMIR.BITNET:KVC@ENGVAX.SCG.HAC.COM@SMTP 28-JUL-1987 22:21
To:	EVERHART
Subj:	Disconnecting a virtual terminal

Received: from wiscvm.wisc.edu by KL.SRI.COM with TCP; Tue 28 Jul 87 02:36:20-PDT
Received: from YMIR.BITNET by wiscvm.wisc.edu ; Tue, 28 Jul 87 04:34:24 CDT
Received: from ENGVAX.SCG.HAC.COM by YMIR.BITNET; Tue, 28 Jul 87 02:35 PDT
Date: Mon, 27 Jul 87 14:02 PDT
From: Kevin Carosso <@YMIR.BITNET:KVC@ENGVAX.SCG.HAC.COM>
Subject: Disconnecting a virtual terminal
To: info-vax@sri-kl.ARPA
X-VMS-To: INFO-VAX-SUBMIT

> Sorry to bother the entire net with this, but CSNET couldn't/wouldn't
> recognize Kevin's address!

That's funny...  Historically, CSNET has been one of the few that DID
understand my address...

>  Could you clue me in on the CLASS_DISCONNECT you described?  I've
>  recently written such a beast, trying to DISCONNECT idle processes,
>  instead of blowing them away, but have had some problems.  I chose to
>  go to the fiche and "emulate" the DCL DISCONNECT command using the
>  IO$M_DISCON modifer.  This seemed to work just fine, EXCEPT, DCL has an
>  outstanding read request which must be cancelled, which I've done.  BUT
>  this TOO causes some problems, which we've learned to live with for the
>  time being.

Yes, there is a QIO SETMODE modifier that does a disconnect.  Unfortunately,
it gets queued behind any outstanding read QIO's that might already be on
the terminal.  An idle terminal nearly ALWAYS has a read sitting on it,
usually from DCL.

There is an entry point in the TT class driver that terminal port drivers
call when they need to "disconnect".  Note that "disconnect" in this context
is more general than you might think.  If a terminal cannot be disconnected,
the class driver will send a hangup, but it's all the same to the port driver,
it calls the same entry point.  This is what, for example, the DMF port driver
calls when modem signals indicate a phone line has hung up.  Or, it's what
I made the CMU pseudo-terminal driver do when the master process goes away
for some reason (if you TELNET and lose your network connection for example).

The code to do a disconnect basically figures out if the device in question is
valid, goes into kernel mode, finds the UCB for the terminal, gets the
physical UCB, gets the class/port interface base vector, and calls the
CLASS_DISCONNECT entry point -- thus doing the same thing the port driver
would've done if it thought it should.

I'm sending the code in a followup message to this one on the form of a
subroutine you can call.  Currently it checks that the device is disconnectable.
It needn't be, since it would still be a nice way to delete process' that
aren't on a disconnectable terminal.  They would get a hangup AST instead
of a DELPRC.  I didn't bother to remove the check since you'd still have
to make SOME check and not do anything if the terminal is an RT.

The code was originally a midnight hack by Forrest Kenney.  I modified it
somewhat.  I hope it doesn't crash your system, but I of course make absolutely
no guarantees.

        /Kevin Carosso                     kvc@engvax.scg.hac.com
         Hughes Aircraft Co.               kvc%engvax@oberon.usc.edu