sun3/60 with apple laserwriter IINT

[Christopher Kolb]

i wrote a while back about what was needed to insure to the
interoperability between a sun3/60 (or any sun, using the serial line port
on the processor board) and an apple laserwriter IINT.

i received plenty of responses, the majority of which were requests to
pass this answer on when i had gotten to one.  so i decided to go public
with my findings (i never did get it working, and it has been shipped to
it's user who will have use cat instead of lpr...

of the suggestions i received, some only might have helped if i were
running sun os 4.0 (using a new printcap tag that describes the attributes
of the rs232 line), while others were flat wrong (yes, you do *need* the
null modem adapter or a null modem cable).

others however were on target.  the handshaking should be set to XON/XOFF,
*not* DTR.  this is because the sun is not fast enough to handle the
interrupts generated by hardware handshaking.  also, it should be set to 8
data bits and one stop bit.  the line speed in 9600 b/s.

using this configuration, i am now able to cat postscript files directly
to the laserwriter, and it does the right thing. this is done like
below...

  (stty 9600; cat stupid.ps) > /dev/lp

i am also able to use 'tip' to type postscript commands directly to the
interactive postscript interpreter that is built in to the laserwriter.
again, it does the right thing.

so the communications seem to be set up correctly, as does the laserwriter
itself.  yet lpr still does not work.  so the postscript filters are now
suspect.  i am running transcript 2.0.  i know about the communications
problems (pscomm), without knowing exactly what those problems are.  it
was suggested that we upgrade to 2.1, and it is on order, which means that
we may get it 6 to 8 weeks from now.  the 2.0 stuff works on our other
laserwriter that is wired up to a port on an alm2.  it works just fine
(well...  it works well enough for the time being).

the symptoms are that i invoke 'lpr -Pps -h file-name' and what is see
running is the ps filter 'psof' (which is supposed to invoke psbanner).
this process hangs out for awhile and then dies.  the green light on the
lw that signifies that a job has started and eof has not been seen yet,
never blinks.  the job forever stays in the print queue until it is
manually removed.  (btw, if i give lpr the -h flag, wouldn't that mean
that psbanner shouldn't get run and that the psif filter should be used
instead of the psof filter) (btw2, i never do see the psbanner process
itself running...)

so that's the end of my tale.  i no longer have the lw on my desk to play
with.  but i am still curious as to why it wouldn't work.  any ideas out
there...


christopher kolb
NYSERNet, Inc.
Network Information and Support Center