Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site uw-beaver Path: utzoo!watmath!clyde!cbosgd!ulysses!mhuxr!mhuxt!houxm!vax135!cornell!uw-beaver!laser-lovers From: laser-lovers@uw-beaver Newsgroups: fa.laser-lovers Subject: Apple Laserwriter XON/XOFF Problem Message-ID: <1679@uw-beaver> Date: Mon, 28-Oct-85 13:26:49 EST Article-I.D.: uw-beave.1679 Posted: Mon Oct 28 13:26:49 1985 Date-Received: Tue, 29-Oct-85 04:46:36 EST Sender: daemon@uw-beaver Organization: U of Washington Computer Science Lines: 60 From: joseph@SCRC-QUABBIN.arpa Date: Tue, 22 Oct 85 12:34 EST From: Allan HetzelWe 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