The general flow of a job through the base operating system spooler is depicted in the following figure.
Figure 3-1. Printing with the Base Operating System
There are four commands that can be used to submit a job to the base operating system spooler. These are lp, lpr, qprt, and enq. Each of these commands has a specific UNIX origin; lp originated with AT&T System V, lpr originated with BSD, and both qprt and enq originated with the base operating system.
While a user can use any one of these four commands to submit a job to the spooler, the true entry point to the spooler is the enq command. All of lp, lpr, and qprt are front ends to enq. lp, lpr, and qprt all parse their arguments and compose a call to enq. The front ends differ from one another in the way each one behaves and in the number and types of flags each one accepts.
When a job is submitted to the spooler, enq processes the job request. If the job request is valid, which basically means that the command syntax was correct, the job is placed upon a queue. enq creates a job description file (JDF) and notifies the qdaemon of the existence of the new JDF.
The qdaemon reads each new JDF and reads the job parameters specified by the JDF into an internal data structure that it maintains to track job requests. The qdaemon uses queue status information to keep track of the status of each queue and, when circumstances are right, will invoke the backend for the queue to process the job.
The backend for a queue determines precisely how a job placed on that queue will be processed. The commands that allow users to submit jobs to the spooler can specify flags requesting certain treatment of the job, the qdaemon can determine which job gets processed when (shortest-job-next or first-come-first-served), but the backend is the process that actually does all the work as far as processing the job is concerned. (A systems administrator can read the stanzas in /etc/qconfig and quickly determine the function of a given queue simply by examining the backend.)
In the Printing with the Base Operating System figure , the two most common backends scenarios are shown: a local printer queue and a remote printer queue. The local queue uses piobe (Printer Input/Output BackEnd) as a backend. The remote printer queue uses rembak (REMote BAcKend) as a backend.
piobe, like all backends, is invoked by the qdaemon. piobe sets up and controls a series of programs ( a pipeline) that can not only perform extensive manipulation of a print job but can also send an extensive amount of control data to a printer, for instance to initialize the printer to a specific mode before the processed job is delivered to the printer. It is piobe that makes the initial use of the data stored in printer colon files. The last program in the pipeline set up and controlled by piobe is responsible for the physical delivery of the byte stream generated earlier in the pipeline. In the context of a local queue, this program opens a device driver which will deliver the byte stream to a locally attached printer (attached serial or parallel), or to a network-attached printer.
rembak is a common backend when the remote printer queue simply points to a queue on another host, better known as a print server. While piobe can perform extensive manipulation of a print job, rembak just transfers jobs across TCP/IP networks to print servers. As the Printing with the Base Operating System figure depicts, if the print server is another base operating system-based machine, rembak transfers the job across the network to the lpd process, which in turn invokes enq, which creates a JDF, and so on as described above.