Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!EREBUS.STANFORD.EDU!farrell From: farrell@EREBUS.STANFORD.EDU (Phil Farrell) Newsgroups: comp.protocols.appletalk Subject: Curious lwsrv behavior with new LaserWriter Message-ID: Date: 2 Nov 88 19:04:21 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 50 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?