Subject: pap, pfs, and repreating printjobs

From: [email-masked] (Jurgen Botz)
Date: Thu, 18 Nov 1993 17:20:21 -0500 (EST)

I have a Laserjet IVsi with Ethertalk interface, and a bunch of Sparcs
(SunOS 4.1.3) of which one is an lpd server for the HP.  Printing is 
done with pap & psf from netatalk-1.3b2.  Every now and then, under
circumstances I have not been able to isolate, a job "re-appears" in
the queue shortly after having successfully printed, and the gets
printed repeatedly until someone notices and kills the queue.  I have
been told that this behavior has been seen in cases where a filter
returns an incorrect result code, so pap and/or psf seems a likely
culprit.

Has anyone else seen this behavior?  There isn't anything useful in
the error logs... how can I get more information on what pap/psf are
doing?

--
Jurgen Botz, [email-masked] | ``Accountability is the price of openness''
South Hadley, MA, USA            | - Daniel Geer

---

From: [email-masked]
Date: Fri, 19 Nov 1993 10:50:10 -0500

> From:    [email-masked] (Jurgen Botz)
> To:      [email-masked]

> Printing is 
> printed repeatedly until someone notices and kills the queue.

There are two problems.  The first, and the one which is holding up
our efforts to include printer accounting in netatalk, is that many
printers, under certain circumstances, will not send us an EOF.  The
PAP protocol looks like this:

	Client			Server
	------			------
	OPEN	->
			<-	OPENREPLY
	WRITE	->
	:		<-	WRITE
	EOF	->		:
			<-	EOF
	CLOSE	->
			<-	CLOSEREPLY

Now, after the server sends EOF, the client can do another write,
implicitly beginning another file in each direction, both of which must
be closed.  Each time the client closes its file, the server can
continue to write data back, until it has finished processing the job
and sends an EOF.

Some printers don't always send an EOF.  There is some code in pap
which will make it not wait for the printer to send an EOF before
closing the connection.  The second problem is that in 1.3b2, that code
is under a #ifdef that isn't defined.  In particular, #ifdef
xPRAGMATIC.  If you are having the problems that Jurgen describes, you
should change all occurences in bin/pap/pap.c of xPRAGMATIC to
PRAGMATIC, recompile, reinstall, etc.  The impact of doing this, aside
from fixing the problem, is that the lpd status file won't get updated
once the connection is closed down.  So, if your printer has a lot of
memory, so it can accept a lot of data before it prints, pap will close
the connection down very often, before the first page prints.

We are working on a work-around, that won't close the connection so
early.  I don't think we're going to hold up the 1.3 release for it,
tho.

:wes