info-vax@ucbvax.ARPA (11/27/84)
From: <OTHB@SRI-KL.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? I have a DIABLO 1650 printer as a queued terminal device at 1200 bps, and it gets itself stuck several times a week. The simplest way I have found to clear the deadlock is to yank the Diablo's cable out of the DZ, plug in a VT-100, set VT-100 to 1200 bps, hit control-Q, and replace the cables. The printer people say the Diablo is fine, DEC says the DZ, UNIBUS and VMS are fine, and I am tired of fiddling with cables. $STOP/NEXT, STOP/ABORT, and DELETE/ENTRY= all fail if there is a current print job active and VMS is waiting for an XON. One software solution I have found is to reboot the 780, but that is a bit extreme. Any suggestions on a less painful solution? advaTHANKSnce, Jon Spear -------
info-vax@ucbvax.ARPA (11/27/84)
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
-------info-vax@ucbvax.ARPA (11/28/84)
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!!!]