[comp.protocols.appletalk] bug in CAP "idle printer" fix?

mkupfer@acornrc.UUCP (Mike Kupfer) (12/23/87)

We're running CAP version 4, with patches through number 7 applied, on a
network of Suns.  In particular, clients (3/60's) send print jobs to the
file server (a 3/280), which talks to a LaserWriter via a Kinetics box.
Most of the time things work OK, but occasionally the print queue gets
wedged while the printer is idle.  OK, there's an ifdef in papif that
supposedly handles just that problem.  When this ifdef is enabled, papif
notices that the printer is idle, kills off the old daemon, and starts a
new one.

Therein lies the problem.  I installed papif with this ifdef enabled,
and I immediately started getting multiple copies of print jobs.  Near
as I can tell, papif is killing the daemon before it can remove the job
from the queue.  So when the daemon restarts, it reprints the job.
Eventually the job gets finished, but only after 1-3 extra copies have
been printed.

Can someone tell me whether I've screwed up the configuration, or whether
I've stumbled on somebody's bug, or what?

thanks,
mike
-- 
Mike Kupfer, Olivetti Research Center
acornrc!mkupfer@decwrl.dec.com
415-496-6238

cck@CUNIXC.COLUMBIA.EDU (Charlie C. Kim) (12/24/87)

Change the "lpc restart" to "lpc abort; lpc start" to cancel the
current job.  The reason restart was used was ensure that people got
their output.

The real fix is to get rid of bug in the code that throws papif into
the idle state, but this isn't easy.

Charlie

cck@cunixc.columbia.edu (Charlie C. Kim) (12/29/87)

Mike Kupfer points out to me that papif already does a lpc abort, lpc
restart sequence.  Woops.  I just got the TOPS-20s opr abort command
confused with the Unix lpc abort command.

A way to make it die is to do an exit(lpd_OKAY) at that point - it
will make the job look like it has printed.  Often it will have.
Sometime it will not have.

Error recovery in papif is limited, but in almost all cases it
attempts to make sure that at least one copy of the file is printed
(sometimes resulting in many copies).


Charlie C. Kim
User Services
Columbia University