How a Print Job Flows Through a Print Queue


Contents

About this document
    Related documentation
Print job flow steps

About this document

The purpose of this document is to overview the general flow of a print job as it makes its way through the print queue from the time the job is submitted by a user until it gets to its final destination, typically a printer.

This document applies to all Levels of AIX.


Related documentation

For more detailed information, these texts are recommended:

"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 ]