farrell@EREBUS.STANFORD.EDU (Phil Farrell) (11/03/88)
I found that a new LaserWriter Plus needed "breaking in" before it would work with lwsrv (CAP 4.0) on a 4.3BSD Vax connected via serial line. I have been running lwsrv on a Vax for over a year, to allow Macintoshes on an AppleTalk net bridged to the Ethernet via a Kinetics FastPath to print to a LaserWriter connected to the Vax via serial line (we use the TranScript spooling software on the Vax). A while ago, we installed a LaserWriter Plus to the same Vax on another serial line. Now we want to let the Macintoshes print to the LWPlus as well, so I started up a new lwsrv daemon for it just like my one that has been running so well, but files sent from a Macintosh would not print. Lwsrv accepted the file from the Macintosh and correctly spooled it on the Vax. A header page (sent by the TranScript software) printed, but no file. The error file on the Vax claimed that one of the first lines in the AppleDict file prepended by lwsrv had an "OffendingCommand" named "setdefaulttimeouts", so the job was flushed. The same file from my Mac printed okay on the first LaserWriter. I verified that the exact same file, including same AppleDict, was being sent to the two different LaserWriters by stopping the queues on the Vaxes and comparing the spool files that were waiting to print. Now, as far as I could tell, everything on the Vax end was the same for the two LaserWriters, but spool files from a Mac printed on one and not the other. There were only two differences between the two LaserWriters: a) The working one is a plain LaserWriter; the failing one is a Plus. b) The working one had originally been connected to an AppleTalk net and had received Macintosh files directly in its distant past (over a year ago); the failing one had never been connected to an AppleTalk net, but had spent its entire life so far tethered to the Vax via serial line. My hypothesis was that something in non-volatile RAM (had to be non-volatile because the working LW had been power cycled many times since it was switched from AppleTalk to serial line connection) gets initialized the first time a Macintosh prints directly to the LW via AppleTalk, and that this setting is necessary for the LW to correctly interpret AppleDicts sent to it later via lwsrv on the Vax. The hypothesis was easy to test: we temporarily switched the failing LWPlus to AppleTalk input; connected it to a Macintosh; sent a one-line MacWrite file to it from the Mac (which printed okay); switched it back to serial line input from the Vax; and power cycled it. The result: it works! Now files from lwsrv on the Vax print correctly. The moral: "break in" your new LaserWriters by printing a file directly from a Mac via AppleTalk before trying to access them with lwsrv on a UNIX host connected via serial line. Does anyone have any idea what is being set inside the LaserWriter by this procedure?
davy@RIACS.EDU (11/06/88)
From: Phil Farrell <farrell@erebus.stanford.edu>
Date: Wed, 2 Nov 88 11:04:21 PST
Subject: Curious lwsrv behavior with new LaserWriter
[....]
The error file on the Vax claimed that one of
the first lines in the AppleDict file prepended by lwsrv had an
"OffendingCommand" named "setdefaulttimeouts", so the job was flushed.
The same file from my Mac printed okay on the first LaserWriter. I
verified that the exact same file, including same AppleDict, was being
sent to the two different LaserWriters by stopping the queues on the
Vaxes and comparing the spool files that were waiting to print.
The moral: "break in" your new LaserWriters by printing a file directly
from a Mac via AppleTalk before trying to access them with lwsrv on a
UNIX host connected via serial line. Does anyone have any idea what is
being set inside the LaserWriter by this procedure?
I don't know what "setdefaulttimeouts" does, but I ran into the same
problem brining up our QMS PS2400 under lwsrv. I just deleted the
"setdefaulttimeouts" command and the associated if-then-else from the
Appledict files, and it was all happy.
I haven't tried running these files to a LaserWriter, but as near as I
can tell, the deletion of "setdefaulttimeouts" makes no difference.
--Dave Curryliam@cs.qmc.ac.uk (William Roberts) (11/08/88)
In article <Added.MXPppWy00UkT0Dm08y@andrew.cmu.edu> farrell@EREBUS.STANFORD.EDU (Phil Farrell) writes: >I found that a new LaserWriter Plus needed "breaking in" before it would >work with lwsrv (CAP 4.0) on a 4.3BSD Vax connected via serial line. >... >The moral: "break in" your new LaserWriters by printing a file directly >from a Mac via AppleTalk before trying to access them with lwsrv on a >UNIX host connected via serial line. Does anyone have any idea what is >being set inside the LaserWriter by this procedure? This must be another example of the insane way that Apple handle PostScript - every new LaserPrep file I see is distinctly more unpleasant than the last, whilst also conforming more precisely to the letter of the Adobe document convention: Example: DSC 2.0 "Every page should be independent of every other page" LaserPrep: Ok, in Document setup we produce a procedure which enumerates the current clip path in device coordinates and use that to completely reset the the printer at the start of every page. I'd send Apple a copy of the PostScript Green Book if I thought it would do any good... -- William Roberts ARPA: liam@cs.qmc.ac.uk (gw: cs.ucl.edu) Queen Mary College UUCP: liam@qmc-cs.UUCP LONDON, UK Tel: 01-975 5250