laser-lovers@uw-beaver (10/23/85)
From: Allan Hetzel <SYSAL%UKCC.BITNET@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 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. Allan Hetzel Computing Center University of Kentucky
laser-lovers@uw-beaver (10/28/85)
From: joseph@SCRC-QUABBIN.arpa
Date: Tue, 22 Oct 85 12:34 EST
From: Allan Hetzel <SYSAL%UKCC.BITNET@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 CenterFURUTA@WASHINGTON.ARPA (10/28/85)
From: joseph@SCRC-QUABBIN.ARPA
Date: Tue, 22 Oct 85 12:34 EST
From: Allan Hetzel <SYSAL%UKCC.BITNET@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 Centerlaser-lovers@uw-beaver (11/01/85)
From: Allan Hetzel <SYSAL%UKCC.BITNET@WISCVM.arpa> The note posted to Laser-Lovers on Oct 28 by Joseph Goldstone of Symbolics Cambridge Research Center was helpful but I didn't try his suggested fix correctly and so I called Adobe. They were very helpful (much more so than Apple) and explained the problem and how to bypass it. My apologies to Adobe if this not an accurate description of the problem. The problem apparently is due to the PostScript interpreter getting confused by what it thinks is an excess of white space characters. The bypass is to place a special character (parenthesis, bracket, brace, slash, etc.) to the right of some token, but without an intervening white space character. As the PostScript scanner reads the token it also reads the special character which acts as a delimiter. The scanner then has to back up one character so that it can reprocess the special character after it has processed the preceding token. During this backing up process a number of internal values are recalculated, including some pointer into the input buffer. This causes the XON/XOFF protocol to work properly. Doing this once per page seems to keep everybody happy. Each page in the PostScript file built by our word processing program is surrounded by a "save restore" sequence. We changed the beginning save sequence "/saveobj save def" to read "/saveobj save def() pop". The "() pop" is effectively a no-op and we are assured that the necessary recalculations are done on each page. This seems to have corrected the problem completely. Allan Hetzel (sysal@ukcc.bitnet)