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!burl!ulysses!mhuxr!mhuxn!ihnp4!houxm!mtuxo!mtunh!mtung!mtunf!ariel!vax135!petsd!pesnta!greipa!decwrl!decvax!ucbvax!info-vax
From: info-vax@ucbvax.ARPA
Newsgroups: fa.info-vax
Subject: Disconnecting??
Message-ID: <8962@ucbvax.ARPA>
Date: Fri, 12-Jul-85 02:02:18 EDT
Article-I.D.: ucbvax.8962
Posted: Fri Jul 12 02:02:18 1985
Date-Received: Sat, 13-Jul-85 16:14:54 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 26

From: *Hobbit* 

I found the bit in the I/O users guide that sez that a setmode QIO with 
the IO$M_HANGUP modifier will disconnect a virtual terminal.  I have been
playing around with this a bit and find that it ain't necessarily so.

First of all, if you make that a qiow, you sit there forever until the person
you are trying to zap types something on his terminal with a line terminator.
Doing $set term/hang tqxn: has the same effect.  If the terminal is not set
/modem, you'll never be able to hang it up, and likewise /disconnect.  My
question is, how do I reliably bash dialups without having to wait for the
terminal driver to decide that I *really* want that line disconnected?  This
waiting around is a pain, and doesn't work all the time, and a straight qio
with no wait doesn't work at all.  What *should* the documentation have 
said?

As an aside, while I was playing with this using RTAn: connections, I crashed
the machine twice.  The foreign end said something about data set hangup,
while the local machine [where the forced-disconnect had taken place] got very
bent out of shape and eventually lost its lunch [like when I went into NCP and 
tried setting the circuit off].  Since RTDRIVER doesn't support disconnecting,
I wouldn't really expect this to work, but Decnet should be  able to recover
from what it sees as a dataset hangup much more gracefully than this.

_H*
-------