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

[Helge Blischke]

Kai Lanz wrote:

> 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

Well, HP devices ...

I have no experience with real HP plotters but with a bunch of HP laser 
printers, most of them with their own built-in print server. Depending on 
their hardware properties - size of the built-in memory, hard disk etc - 
they tend to release the TCP connection as soon as they have encountered the 
end of the data stream (if a hard disk is present, even local spooling can 
be configured). Thus, they can accept the next job's data before the 
printing of the current job has finished.

I'd suggest to try the following two variants:

(1) from your script, call the CUPS socket backend from your script:
using the propoer port number (usually 9100). It is known to wait for the 
printer to shut down the connection and doesn't by default close the 
connection at EOF.

If that does not work, your could

(2) try my hpnpf filter (source code available via the links page of the 
CUPS web site) using the device_uri

hpnpf://escher.stanford.edu/9100

(or onother suitable port number; consult your plotter's manual). It 
encapsulates the job data by PJL commands that cause the printer (at least 
all HP printers I ever tried it with) to shut down the connection only when 
the printing has finished and reports the printer's backchannel messages to 
a speical log file in /var/log/cups.

Helge