How a Print Job Flows Through a Print Queue

Contents

About this document

This document applies to all Levels of AIX.

Related documentation

"The AIX Guide to Printer and Printing" (order number SC23-2783)

"Printing for Fun and Profit" (order number GG24-3570)

Print job flow steps

1. The user queues up a print job:

           lp -d qname -o option1 -o option2 -o option3 filenames
      OR   qprt -P qname  option1 option2 option3 filenames
      OR   enq -P  qname option1 option2 option3 filenames  
      OR   lpr -P qname option1 option2 option3 filenames
      OR   from lpd daemon
      OR   from dtprint (on the CDE desktop)
   

2. AIX print command submits job to enq
   

   If the command used to queue the print job was lp, qprt, lpr but not enq, the flags are translated into an equivalent enq flags and the enq command is invoked. For example:

   lp -d qname /my/file The lp command does nothing more than invoke: enq -P qname -j -- /my/file

   For the lpr command the defaults for:

   lpr -P qname /my/file include the -c and -Bgn flags which cause a header page and print spooling as shown here: enq -P asc -c -Bgn /etc/motd

   The qprt flags are passed to enq as -o flags:

   qprt -p12 -z+ -P qname /my/file which generates the following enq command enq -o -p -o 12 -o -z -o + -P qname /my/file

3. The enq command creates a JDF (job description file) in the /var/spool/lpd/qdir directory with the filename ##user:qnamexxxxx for your job.

   The ## is a rank number, the user is the user who submitted the job, and the queue is the queue to which the job was sent. Starting at AIX 4.2.1 there is a series of characters at the end of the file to make the name unique.
   The following shows the directory listing of /var/spool/lpd/qdir with jobs queued at AIX 4.2.1. The naming convention for this file changed at AIX 4.2.1 to allow a much larger number of files for a user to a single queue.

   -rw-rw---- 1 root printq 3828 Jul 8 15:36 n0jwtesch:pcl$#@!pBib -rw-rw---- 1 root printq 3810 Jul 8 15:38 n0root:asc$#@!rBUc -rw-rw---- 1 root printq 3837 Jul 8 15:40 n0root:asc$#@!rC7c

   The flag information is passed from enq to the qdaemon in the JDF at the end of the file as shown below:

   -Pasc -Bgn <-- enq flags STDIN.18024 <-- file name rocky <-- User submitting the job tesch <-- System with job 0 $#@!-p <-- non-enq flags (Other flags $#@!17 $#@!-z $#@!+ /var/spool/qdaemon/tS0rC7a 2 <-- File to print

   Then, enq signals the qdaemon to let qdaemon know that a job has been queued.

4. When the print queue to which the job was submitted is idle, qdaemon will examine /etc/qconfig.bin (a "compiled" version of /etc/qconfig) and the JDF file to determine how to handle the print job. Suppose that /etc/qconfig contained this entry:

   qname: device = lpxxx lpxxx: file = /dev/lp0 backend = /some/backend optiona optionb optionc

   and a user queued a print job to this queue:

           qprt -P qname option1 option2 option3 /some/file
   

   The daemon would invoke the backend program, passing it any arguments found in the qconfig file, followed by any command-line arguments that are contained in the job description file. The last command-line argument is always the name of the file to be printed.
   

   No standard input can be piped to the backend program - the backend must accept its input as a filename residing in the last command-line argument.

   NOTE: that if a pipe is involved in queueing up the job (eg. lptest|enq -Pqname) or the job is spooled with the -c flag to enq, data is first copied into a temp file in /var/spool/qdaemon and then the name of the temp file is passed to the backend as the last command-line argument. Be sure /var has enough room to accommodate the amount of space needed to store the copy.

   So, with the qconfig entry and command shown above, qdaemon would invoke:

      /some/backend optiona optionb optionc option1 option2 option3 /some/file
   

5. What the backend program does and what the options mean to the backend is entirely up to the backend. Typically it formats the data for printing. In the case above, the qconfig entry has a file = /dev/lp0 line. So, qdaemon sends the stdout of the backend program (if the backend produces any output) to the file /dev/lp0.

   Since the "file = " is arbitrary, output of a queue could be sent to a file, to a tape drive, or practically anything. A backend program does not even need to be related to printing. For example, if your backend program is /bin/ksh, then Korn shell scripts could be queued to the queue and executed sequentially. Any output would go to the file = file.

   A queue can be used for nearly any tasks that should be done one at a time.

6. The qdaemon continues to process other jobs for other print queues while waiting for the backend program to exit. When the backend program exits, qdaemon checks the exit code of the backend. If the program exits with an exit code of 0, the job completed successfully and the next queued job is processed in a similar fashion. If the exit code is 64, the queue is taken DOWN and the job remains queued. When the queue is enabled, step 4 is repeated.

   Print Backend Exit Codes
   Exit Code	Description
   0	successful
   64	Take the queue down, and keep job queues
   101	bad flag, bad load, bad file open, etc.
   102	printer failed
   103	filter terminated; printer OK
   104	filter terminated; printer not printing
   105	job cancelled; printer OK
   106	job cancelled; printer not printing

   These exit codes are undocumented and therefore subject to change without notice.

This is a highly simplified overview of the process of processing jobs through the AIX spooler. Queues can have multiple devices so jobs sent to a queue go to the first idle device. Special backend programs such as piobe are quite complex and can invoke user-defined filters and formatters to process the queued jobs.

[ Doc Ref: 91805849017168     Publish Date: Feb. 13, 2001     4FAX Ref: 6425 ]