Can we limit the number of active jobs on a given printer?

[Kai Lanz]

Helge Blischke wrote:

> Kai Lanz wrote:
>
> >     /bin/cat $FILE | /usr/local/etc/dosprstrip | /usr/local/etc/hppjlstrip
> >     | \
> >         /usr/bin/enscript -B -h -p- -q -Z | \
> >         /usr/local/sbin/lpr -h -Y -k -P ${qname}@${printer}.${domain}

> If I interprete your /usr/local/sbin/lpr command correctly, the "-Y -k"
> prevents spooling on the local client but not on the host that manages the
> printers itself.

That's my understanding, yes.

> Thus, your backend exits if the print job has successfully transferred to
> the print server.

Yes. And in our case, the "print server" is the plotter itself.

There is no additional "print server" host -- the backend script shown above runs on our print server and sends print jobs directly to the plotter via lpr with no intermediate hosts. The lpr command actually looks like this:

    /usr/local/sbin/lpr -h -Y -k -P BINPS at escher.stanford.edu

where escher.stanford.edu is the DNS hostname of the plotter, and BINPS is the
queue to print to on the plotter. (Other queues are RAW, TEXT, and AUTO.) These
plotters accept input in a few different protocols, including lpd; that is, they
run their own line-printer daemon and maintain their own internal job queue.
This is basically transparent to us and has always worked fine.

> Assuming that the printserver uses LPRng as well, you need
> to implement a lpc loop to check if the job has been printed successfully.

I'm not sure how lpc would help us... I can't run it on the plotter, obviously,
and I don't imagine the HP plotters use LPRng internally, anyway. Or are you
suggesting we run lpc in our backend script, after the call to lpr?

--
Kai