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* -------