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!burl!ulysses!cbosgd!ucbvax!info-vax
From: info-vax@ucbvax.ARPA
Newsgroups: fa.info-vax
Subject: Re: XOFF Deadlock on R.O. Diablo. Help!
Message-ID: <3497@ucbvax.ARPA>
Date: Tue, 27-Nov-84 10:47:50 EST
Article-I.D.: ucbvax.3497
Posted: Tue Nov 27 10:47:50 1984
Date-Received: Wed, 28-Nov-84 04:26:11 EST
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 35

From: Jerry Leichter <Leichter@YALE.ARPA>

    	Is there any way to unjam a receive-only printer that VMS thinks has
    sent an XOFF when the printer cannot be coaxed into sending an XON?  A
    way, perhaps to poke a character into VMS's input buffer for that device?
    
    ...

You can reset the XOFF condition directly.  What you need to do is a Set Mode
QIO on the terminal with the TT2$M_XON bit set.  Note that you need to be able
to access the terminal line to do this - you'll probably want to change the
software driving your printer to do this every so often (or in response to
some sort of request).  Failing that, you can stop the process that has
control of the terminal line, assign it, run a program to clear the XOFF
condition, deassign the terminal, and restart the spooler program.

Details on the Set Mode QIO you need are in the I/O User's Guide, Volume 1.
(For the V3 documentation set, look at pages 9-22 and 9-29.)

A question:  Are you sure your printer really needs XON/XOFF?  If it doesn't
need it, disable TTSYNC on the line in question and XOFF's will have no
effect, eliminating the problem at the source.  If the printer really IS using
XON/XOFF, the fault is highly likely to be its problem; it's hard to see how
VMS can miss the printer's XON's so often.  (You'd notice VMS missing XON's
from a terminal - you'd hit CTRL/Q and nothing would happen.  If this happens,
it's VERY rare.)  One question:  If you turn the printer off and on, does that
clear the problem?  (You imply it doesn't by talking about re-booting as a
solution!)  A device that uses XOFF/XON control should normally send an XON
when it resets (or powers up) so as to set the line to a known state.  (Well,
it could send XOFF, but THAT known state seems a bit less useful.)  If it
doesn't, then the printer is likely to get into the jammed state you describe
any time it resets for some reason - power glitch, error - after sending an
XOFF.
							-- Jerry
-------