[ Previous | Next | Contents | Glossary | Home | Search ]
AIX Version 4.3 Guide to Printers and Printing

/etc/qconfig, the Spooler Configuration File

/etc/qconfig File Structure

/etc/qconfig is the most important file in the spooler domain, for these reasons:

/etc/qconfig describes all of the queues defined to the AIX operating system; a queue is a named, ordered list of requests for a specific device. A device is something (either hardware or software) than can handle those requests one at a time. The queue provides serial access to the device. Each queue must be serviced by at least one device; often it can be handled by more than one device.

The qdaemon reads the ASCII version of /etc/qconfig and creates a binary version, /etc/qconfig.bin. /etc/qconfig must adhere to a specific structured format in order for the qdaemon to be able to parse it. This format is detailed in the /etc/qconfig File Structure examples below.

                Local Queue
queue_name:
        device = device_name
        up = TRUE or FALSE
        discipline = fcfs or sjn
device_name:
        file = physical_device_name or FALSE
        header = always or group or never
        trailer = always or group or never
        access = both or write
        backend = full_path_name_to_backend_program 
  
                Remote Queue
queue_name:
        device = device_name
        up = TRUE or FALSE
        host = remote_hostname
        s_statfilter = full_path_to_short_filter
        l_statfilter = full_path_to_long_filter
        rq = remote_queue_name
device_name:
        backend = full_path_name_to_backend_program

/etc/qconfig is composed of text blocks referred to as stanzas. Each queue is represented by a pair of stanzas. The first stanza in a pair is referred to as the queue stanza; the second stanza in a pair is referred to as the device stanza. Stanzas are composed of parameters and parameter values that describe the queue's properties and function.

When the qdaemon parses the ASCII version of /etc/qconfig, the first non-commented line it identifies must be a word followed by a colon; this line represents the beginning of the queue stanza. This word is the name of a queue to which a user can submit jobs. There must be one or more lines indented by tabs following this line. One of these lines must be device = device_name. The value of the device parameter is a link from the queue stanza to the device stanza; this parameter has no other function. When a queue is initially setup, the operating system will frequently use the name of a printer, such as lp1, as the value of the device parameter. While the queue may actually be setup to use lp1, the use of lp1 as the value of the device parameter only means that the device stanza will be named lp1. This is not related to the fact that there is a real printer known to the operating system as lp1.

Following the tab-indented lines, the qdaemon must find the word that is the value of the device parameter followed by a colon; this line represents the beginning of the device stanza. This word, which a user normally does not need to know, is the name of a device to which the corresponding queue stanza provides serial access. There must be one or more lines indented by tabs following this line. One of these lines must be backend = full_path_name_to_backend. In a local spooling environment, there are two parameters of critical importance in this stanza.

The file parameter specifies the real device to which the queue provides serial access. It is important to note that jobs submitted to the spooling system are queued upon this device. If a queue is setup to use a printer known to the operating system as lp1, then the value of the file parameter would be /dev/lp1. The operating system routines that create queues use the name of the real device as the name of the device stanza by default, and this is why there is some confusion as to the meaning of the device parameter.

The backend parameter specifies the full path to the program that will process the job submitted to the spooling system, once the qdaemon determines that the job's turn to be processed has arrived.

Spooler Queues, Virtual Printers, and Physical Printers

The Four Queues - Four Virtual Printers - One Physical Printer example depicts an instance of /etc/qconfig that defines four queues on a single physical printer, in this case /dev/lp1. Notice that all four pairs of stanzas use the string lp1 to connect a queue stanza to a device stanza. It is the file parameter in each device stanza that specifies that the printer known to the AIX operating system as lp1, and whose device driver entry point is /dev/lp1, is the actual physical destination of any jobs submitted to any of these queues. When these queues were defined, via smit, the command that actually creates the queue definition needed a string to connect the two halves of each stanza pair. Since the physical printer at hand was lp1, the string lp1 was used as the both the value of the device parameter in each queue stanza and as the name of each device stanza. This format is detailed in the /etc/qconfig File Structure examples below.

asc:
        device = lp1
lp1:
        file = /dev/lp1
        header = never
        trailer = never
        access = both
        backend = /usr/lib/lpd/piobe
gl:
        device = lp1
lp1:
        file = /dev/lp1
        header = never
        trailer = never
        access = both
        backend = /usr/lib/lpd/piobe
pcl:
        device = lp1
lp1:
        file = /dev/lp1
        header = never
        trailer = never
        access = both
        backend = /usr/lib/lpd/piobe
ps:
        device = lp1
lp1:
        file = /dev/lp1
        header = never
        trailer = never
        access = both
        backend = /usr/lib/lpd/piobe

Each of these stanza pairs defines a queue. When the backend for a queue is piobe, each queue also has an associated virtual printer. While it is possible to create virtual printer definitions the hard way, virtual printer definitions are typically created at the same time as the queue definition, via smit and the piomkpq command. The virtual printer definition is not contained in /etc/qconfig. Its presence is implied by the fact the spooler backend for a given queue is piobe, but it is stored elsewhere in the AIX file system. The name of the queue is used to identify and access the virtual printer definition.

The physical printer known to AIX as lp1 clearly supports at least four distinct data stream types; they are ASCII (asc), Plotter Emulation (gl), Printer Command Language (pcl), and PostScript (ps). Each queue with its associated virtual printer definition is designed to process a particular data stream type, hence the four queues. This is the basis for the AIX notion of a logical separation of physical and virtual printers.

Spooler Queue Names and Status Formats

Spooler queue names (the name of a queue stanza) can be over seven characters in length but only the first seven characters will be displayed in the output of a queue status query. Device names (the name of a device stanza) are limited to five characters in the output of a queue status query.

In spooler queue status queries, remote spooler queues will show up twice: once for the local queue, and once for the remote queue on the print server. For instance, if /etc/qconfig contains this entry:

myps:
        device = @kricket
        up = TRUE
        host = kricket
        s_statfilter = /usr/lib/lpd/aixshort
        l_statfilter = /usr/lib/lpd/aixlong
        rq = myps
@kricket:
        backend = /usr/lib/lpd/rembak

the command lpstat -pmyps would return the following:

Queue   Dev   Status    Job Files    User      PP %  Blks Cp  Rnk
------- ---   --------- --- -------- --------- -- -  ---- --  ---
myps    @krik READY
myps    myps  READY

The first line of the output indicates that the local spooler queue named myps, with a device stanza whose name is listed as @krik, has a status of READY. The second line indicates that the target remote spooler queue, also named myps, whose device stanza is listed as myps, also has a status of READY. (It is the author's habit to make a local spooler queue name the same as the print server spooler queue name. It's then easy to visually group the two lines in the output of a spooler queue status query.)


[ Previous | Next | Contents | Glossary | Home | Search ]