User`s guide

3-12
Guide to Printers and Printing
Overview of Backend Processing
The backend for a queue is begun by qdaemon; the qdaemon determines that a job’s turn
to be processed has arrived, sets up an execution environment for the queue backend,
constructs an argument vector for the backend, and, via fork() and exec(), causes the
backend to begin execution.
The number of simultaneous instances of the backend is controlled by the presence or
absence of the file parameter in the stanza for this queue in the /etc/qconfig configuration
file. If the file parameter is present, then only one instance of the backend can exist for this
queue; This is because the qdaemon will only attempt to set the execution environment for
the backend when it has determined that the job can be processed. Part of setting the
backend’s execution environment involves opening stdout of the backend onto the file or
device specified by the file parameter. If the qdaemon has already performed this action for
a previous job, and that job is still executing, then the qdaemon cannot get a lock on the file
or device specified by the file parameter and hence cannot open stdout of the backend onto
that file or device. Thus the qdaemon holds the job in the queue and waits for the previous
job to complete execution and release the file or device. This is how the spooling system
provides and controls serial access to a device.
If the file parameter is absent or set to a value of FALSE, the qdaemon opens stdout of the
backend onto /dev/null and executes the job immediately. In this situation there is no clear
file or device to which serial access should be provided, so jobs will not stack up on the
queue. Jobs submitted to this queue will be processed just as fast as the qdaemon can set
up the execution environment. The absence of the file parameter effectively disables serial
access to any local file or device.
A meaningful and common example of a queue lacking the file parameter is a remote printer
queue. In this situation, the resource to which serial access should be provided actually
exists on another host; there is no reason for the local queue to attempt any type of control.
The backend for this type of queue, by default the rembak program under AIX, simply
sends the job across the network to the remote queue and lets it handle the serial access
control.
The default backend for a local print queue under AIX is piobe. Multiple queues can all
specify the same backend. In this situation, multiple simultaneous instances of piobe can
exist; each queue that specifies piobe as its backend can potentially generate an instance
of piobe. However if two or more queues also specify the same value for the file parameter,
the serial access restriction is applied. The qdaemon will not be able to acquire a lock on
the specified file or device if the qdaemon has already acquired the lock for another
instance of piobe. A queue that cannot process a job because of this restriction will show a
queue status of DEV_BUSY. The status will change to RUNNING as soon as the qdaemon
can acquire a lock on the file specified by the file parameter.
After a job has been submitted to the spooler for processing and after the qdaemon has
accepted the job and determined that its turn to be processed has arrived, the backend for
the queue is invoked. piobe uses a shell to construct and manage a pipeline of filters to
process the job.
The Data stream Flow for Common Print Jobs figure depicts the flow of a job through this
pipeline of filters.