Subject: HP LJ4m pap lossage

From: Chris Metcalf <[email-masked]>
Date: Mon, 13 Dec 1993 16:04:25 -0500

We've been having some problems with an HP LaserJet 4m on LocalTalk which
we recently hooked up.  We're spooling from a SPARC IPC running SunOS
4.1.3 and netatalk-1.2.1, and using a GatorBox to gateway from our Phase
I EtherTalk to LocalTalk, which is what the printer is on.  The printer
works fine with Macs (on ethernet), and our pap works fine with an Apple
LaserWriter II and various TI printers.  It also works fine with short
files to the HPLJ.  I grabbed the latest bin/pap sources from 1.3b2 and
built with -DEBUG -DPRAGMATIC (although I didn't build the 3b2 libatalk).
A short file (enscript /etc/motd) generates the following output:

	Trying 11110.194:128 ...
	OPEN >
	< OPENREPLY
	status: busy; source: AppleTalk
	Connected to Anne's MicroLaser (624):LaserWriter@*.
	READ 1 >
	< TICKLE
	SENDSTATUS >
	< STATUS
	< READ
	DATA >
	SENDSTATUS >
	< STATUS
	< READ
	DATA (eof) >
	< READ
	SENDSTATUS >
	< STATUS
	< READ
	SENDSTATUS >
	< STATUS
	< READ
	SENDSTATUS >
	< STATUS
	< DATA (eof)
	CLOSE >
	< CLOSEREPLY
	Connection closed.

A longer file (still one page, dvips output), never closes the connection,
although it does print the whole file:

	Trying 11110.194:128 ...
	OPEN >
	< OPENREPLY
	status: busy; source: AppleTalk
	Connected to Anne's MicroLaser (624):LaserWriter@*.
	READ 1 >
	< TICKLE
	SENDSTATUS >
	< STATUS
	< READ
	DATA >
	SENDSTATUS >
	< STATUS
	< READ
		[above four lines repeat 24 times]
	DATA (eof) >
	< READ
	SENDSTATUS >
	< STATUS
		[above three lines repeat 4 times]
	< TICKLE
	SENDSTATUS >
	< STATUS
		[activity stop for a while here]
	< READ
	SENDSTATUS >
	< STATUS
	< READ
	SENDSTATUS >
	< STATUS
		[pause]
	< READ
	SENDSTATUS >
	< STATUS
		[15-sec pause]
	< READ
	SENDSTATUS >
	< STATUS
	< TICKLE
	SENDSTATUS >
	< STATUS
		[15-sec pause]
	< READ
	SENDSTATUS >
	< STATUS
		[15-sec pause]
	TICKLE >
	SENDSTATUS >
	< STATUS
		[1-min pause]
	TICKLE >
	SENDSTATUS >
	< STATUS

Curiously, the new pap doesn't notice when I do a pushbutton-reset on
the printer; the old pap disconnected at that point (saying "connection
unexpectedly closed; send file failed").  For the moment we're using
the old pap, and doing a by-hand printer reset after every job spooled
from Unix.

Any insights, or pointers to new pap sources, would be much appreciated!

			Chris Metcalf, MIT Laboratory for Computer Science
			[email-masked]   //   +1 (617) 253-7766

---

From: [email-masked]
Date: Mon, 13 Dec 1993 16:47:19 -0500

> From:    Chris Metcalf <[email-masked]>
> To:      [email-masked]

> I grabbed the latest bin/pap sources from 1.3b2 and

In the 1.3b2 source, look for #ifdef xPRAGMATIC, and change them to
#ifdef PRAGMATIC.  This should fix the problem.

:wes

---

From: Marcus Watts <[email-masked]>
Date: Mon, 13 Dec 93 17:32:56 -0500

You should definitely rebuild pap with the latest 1.3 libatalk you can
find.  There are some rearrangements in atp that should greatly
improve behavior (or at least something beyond 1.3b2.)  It may not
entirely fix things.

The 1.2 version of atp did not support asynchronous operation
at all right.  That's why you are getting those hangs.
The 1.3 version of atp greatly improves things but they're still
not entirely right.  The logic for request retransmits,
tickles, and timeouts is somewhat problemmatical.  This might
not be a big problem for you, especially on a lightly loaded network
or with a relatively low printing load.

If you still experience problems, I may have a fix: I have a fixed
version of pap & atp that (I believe) does tickles & retries almost
correctly.  This fixed version works only with an AIX 3.2 version of netatalk,
which is at this point probably more different from 1.2/1.3 than 1.2 is from
1.3.  (Sample differences: atp uses select not signal for timeouts,
tiemouts for atp_sreqto are measured in ms, not s.  There is a lot
of what Wes would call `crap' in pap to deal with the AIX printing world.)
Unless you enjoy digging deep into libraries & include files and resolving
differences, you may want to just wait & see what happens.  Wes & I are
supposed to meet and talk about differences early next year.  [ In
order not to stall 1.3's release "forever" we decided to postpone this
until after its release. ]  With luck many fixes like this one will make
it into some future "real" release.

			-Marcus Watts
			UM ITD RS Umich Systems Group