Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ucbvax.ARPA
Path: utzoo!watmath!clyde!cbosgd!ucbvax!info-vax
From: info-vax@ucbvax.ARPA
Newsgroups: fa.info-vax
Subject: Re: XOFF Deadlock on R.O. Diablo. Help!
Message-ID: <3509@ucbvax.ARPA>
Date: Tue, 27-Nov-84 21:17:45 EST
Article-I.D.: ucbvax.3509
Posted: Tue Nov 27 21:17:45 1984
Date-Received: Wed, 28-Nov-84 05:10:56 EST
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 27

From: ihnp4!houxm!hou2d!afb3@BERKELEY

There was a similar problem with RSX systems and LA-180 printers
with serial interfaces back in the early days (before such devices
became common place).  I don't remember the actual solution for
a permenent solution, however you could ask someone who has an
old set of SPR's (for version 3.0 of RSX I think).  While this
would not be directly applicable, it may give you some ideas.  With
RSX you could abort the process doing I/O to the diable (the one
with a QIO pending) and the I/O run down would clear the X-on/X-off
bit.  I believe there is also a get/set multiple characteristics
bit in RSX to allow you to do that.  I would expect a similar mechnism
would be available in VMS.  A possible senerio would be 1) abort 
process, 2) run priv. prog. that resets terminal port, 3) restart
printer process (queue manager, spooler??).

If you have software service, run do not walk to you printer and
submit an SPR.  (It might be wise to try this with a DEC printer
or not admit that its  foriegn one!!).

Good Luck,

Al Baldwin
AT&T-Bell Labs
...!hou2d!afb3

[These opinions are my own -- who else would want them!!!]