Symbolics/UNIX LPD glitch?

[cjl@ai.mit.edu (Chris Lindblad)]

    Date: Mon, 1 Oct 90  15:15:49 EDT
    From: delaney@xn.ll.mit.edu (John R. Delaney)

    We had a problem today when we started trying to use the UNIX-LPD hardcopy
    service under Genera 8.0.1. At first we thought it was a problem with the
    Laserwriter being driven by our SUN. My UNIX system wizard sent me the
    following message; does it ring a bell with anyone?

    >I found the cause of the anomalous behavior of lpd on the Symbolics files.
    >Examination of the printer queue showed several jobs with the SAME job ids.
    >The actual data files didn't overwrite each other because they came from 
    >different systems, and thus had different names (i.e cfA741HEMLOCK.LL.MIT.EDU
    >and cfA741ASPEN.LL.MIT.EDU).  I moved the duplicates to a temporary directory,
    >and the rest of the queue is now processing nicely.  However, if this was 
    >anything but a weird case, possibly from restarting the symbolics printer
    >drivers while there were still jobs in the queue here, this is a problem.  
    >Having the same job ids turn up more than once in the queue is a no-no.

If you UNIX system wizard is right, this looks like another case of UNIX
braindamage.  The way the UNIX lpd protocol is designed, clients generate job
IDs only unique on a per client basis, not on a per server basis.  No client
machine, UNIX or lispm, checks whether some other machine has spooled a
printout with the same job id as it.

Even if a client wanted to make sure its job ID's are unique with respect to
jobs already in the queue, it would be real hard.  The UNIX lpd protocol
provides no way for clients to generate job ID's that are unique with all the
other clients, short of having a client use the queue listing command to list
the queue, parse the textual queue listing, and extract the job ID's.

Now it seems that your UNIX system wizard claims that two clients using the
same job id causes the LPD server to choke.  This is either a defect in the
UNIX lpd protocol or a defect in the UNIX lpd spooler, as this can happen with
UNIX clients as well as lispm clients.