Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA Path: utzoo!watmath!clyde!cbosgd!ucbvax!info-vax From: info-vax@ucbvax.ARPA Newsgroups: fa.info-vax Subject: Re: disconnecting... Message-ID: <9039@ucbvax.ARPA> Date: Sat, 13-Jul-85 05:35:22 EDT Article-I.D.: ucbvax.9039 Posted: Sat Jul 13 05:35:22 1985 Date-Received: Sat, 13-Jul-85 15:44:10 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 29 From: Kevin CarossoThe QIO I tried to force a disconnect on a terminal (i.e. how the DISCONNECT DCL command does it) is a IO$_SETMODE ! IO$M_TT_DISCON. There is, I believe, also a IO$M_DISCONNECT, but I was told by an unnamed VMS developer that that one is used for something completely different (I don't even remember what). I never tried it with a IO$M_HANGUP (or whatever), just with the SETMODE. In any case, you will still have the same problem with TT_DISCON, namely that lobbing one at someone else's terminal won't cause anything to happen immediately... The problem is that if that terminal has an outstanding IO request, your QIO just gets put in queue (that's why they call it a QIO, I suppose... :-) until the other guy's read (that's what is usually waiting) is satisfied. Not terribly useful. The solution is to issue the QIO to disconnect, then blast a special kernel AST at everyone else who has a channel to the terminal with an outstanding IO request causing a $CANCEL of that request. This is incredibly gross, and I haven't gotten around to writing it yet. I asked the group many months ago if anyone had any solutions to this problem, but that was the best that came of it. Oh well... Anyone know if it's possible to cancel other people's IO requests without going into their process context? That might make things a little easier, and it kinda gives you that warm feeling all over when you hit the return key to run the program that does it... /Kevin Carosso engvax!kvc @ CIT-VAX.ARPA Hughes Aircraft Co.