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.
See the area labeled 1 in the data stream Flow for Common Print Jobs figure.
When the device upon which the job is queued becomes available, the qdaemon invokes the backend for the queue. In the AIX world, the backend is commonly piobe. The qdaemon invokes piobe and passes it arguments in the normal C programming language fashion, using argc and argv[].
For instance, using the command in step 2 from "Spooler Data Flow Part II":
qprt -Pasc -z1 -fp -p12 -s courier -C -N3 /etc/motd
piobe is passed the following arguments:
argv[0] is the name of the backend itself, as usual. Note that the -Pasc, which specifies the queue name, was parsed out of the original argument vector, as were the -C and -N3 flags and arguments.
See the area labeled 2 in the Data stream Flow for Common Print Jobs figure.
piobe uses the argv[] values to construct a pipeline of filters that must be executed to process the job as requested. After determining the structure of the pipeline, piobe passes the structure to a shell for realization. If the file parameter in the /etc/qconfig entry for this queue exists, piobe will open the stdout of the last process in the pipeline onto the value specified by the file parameter. The last process in the pipeline is not prevented from re-opening stdout onto some other file or device.
Note the parent-child relationship amongst these processes, which is not apparent from the figure:
See the area labeled 3 in the data stream Flow for Common Print Jobs figure.
An optional filter, such as pr, can be specified on the command-line (or hard-coded in the colon file) to perform pre-filtering on the job before pioformat processes it.
See the area labeled 4 in the Data stream Flow for Common Print Jobs figure.
pioformat is known as a device-independent formatter driver. It will dynamically load, link, and drive various device-dependent formatters to process jobs of a specific data stream type (for example, Postscript, ASCII, GL, or PCL).
See the area labeled 5 in the Data stream Flow for Common Print Jobs figure.
Device-dependent code is designed to handle the unique properties of combinations of specific data streams and physical printers. Because combinations of data stream types and printers can be grouped into classes with common attributes, there are currently less than 20 device-dependent modules. These modules are loaded, linked, and driven by pioformat at runtime.
See the area labeled 6 in the Data stream Flow for Common Print Jobs figure.
pioout is the end of the job-processing pipeline, and is called the device driver interface program. The function of pioout is to take the processed data stream and deliver it to the device for which it was intended, generally a printer. In the typical local print queue environment, it is pioout that has its stdout opened onto the character special file in the /dev directory, as specified by the file parameter in /etc/qconfig.
See the area labeled 7 in the Data stream Flow for Common Print Jobs figure.
This is the character special file in the /dev directory that provides access to the device driver for the printer hardware.
