Apple Laserwriter XON/XOFF Problem
laser-lovers@uw-beaver
Date: Tue, 22 Oct 85 12:34 EST
From: Allan Hetzel <SYSAL%UKCC....@WISCVM.ARPA>
We are running several Apple Laserwriters connected to an IBM mainframe
running VM. The connection is through RSCS and an IBM 7171 protocol
converter. Line speed is 9600. We are experiencing the XON/XOFF problem
which is described in the known problems section of the Postscript manual.
(The Laserwriter forgets to send an XON after sending an XOFF. The printer
times out and the job is flushed.) The problem only occurs during long
documents, 50 pages or more. Has anyone else experienced this problem
or have a possible circumvention for it? Our local dealer has tried to
talk to Apple but nothing has been heard from them yet.
I had to deal with this when I was working on LW support for the Symbolics
36xx product line. The fix I finally got from Adobe was pretty gross, and
I can't swear that it has fixed all bugs of this class, but it helped a lot.
Basically the idea is to "whap upside the head" the FSM that reads tokens
from the serial port. I think the FSM really would like to see the tokens
seperated by whitespace, but is prepared to accept unambiguous strings of
self-delimiting tokens. When it encounters the latter, it gets nervous and
recalculates a lot of internal state, including the state involved in the
XOFF/XON calculations. So, hit it often enough and it behaves. [I wouldn't
advocate extending this technique beyond the LW, though.]
The "whap" for me was to insert a ()pop sequence after every string that
got shown, plus at a few other places. I didn't have time to find out what
the minimal number of such sequences were. The disadvantages of this
technique are that you may waste storage storing the LW input (if you are
spooling raw LW bits) and you "waste" your serial bandwidth.
Anybody know if there's a way to ask the LW what ROM version is running?
A different approach, suggested by a friend at Apple, is:
...if you know the LaserWriter is in this *wedged* state,
you can get it out of said state by simply sending down a
XON. Because your end has received an XOFF and nothing since
from the LaserWriter, it may be difficult to get the XON
down the line, but if you can (says [...]) the LaserWriter
will come to life again.
But how do you detect that it's in the wedge-o-matic mode?
Well, if you set a timeout that's just shorter than the LaserWriter's
job timeout, than when your timeout goes off you can send the XON,
restart the LaserWriter, and prevent the world from crashing.
I know that this problem will supposedly be taken care of in the next ROM
upgrade (whenever that is), but that doesn't help much now. I've experimented
with replacing the timeout error handler in errordict with one that sends an
XON but don't have anything which works yet.
My source at Apple tells me these are "January ROMs" but I don't know whether
that's when Apple gets them from Adobe or they start to ship from Apple. And
(as of early September) they hadn't gotten any from Adobe yet, so they couldn't
say whether the bug had been eradicated.
Joseph Goldstone
Symbolics Cambridge Research Center