The commands lp, lpr, qprt, and enq can be used to submit a job to the spooler for processing. The enq command is the true entry point to the spooler; lp, lpr, and qprt all parse their own arguments and compose a call to enq. This can be demonstrated by executing the following steps as the root user at a shell prompt:
The qprt command in step 2 attempts to submit a print job to the spooler and have it placed on the queue named asc, requesting three copies of the message-of-the-day in a 12-point Courier font rotated 90 degrees. qprt parses its command line arguments and builds an argument vector to pass to enq. When the qprt command tries to invoke enq with the argument vector, it instead invokes the echo command, which is mounted over the enq command. Thus the argument vector generated by the qprt command is passed to the echo command, which in turn simply echoes the argument vector to your display. This procedure will work with lp and lpr as well. Aside from demonstrating that qprt really is a front end to enq, this technique is also useful when you are trying to figure out how to get unsupported flags into the spooler. But more on that later.
Execution of the qprt command in step number 2 should cause the following output to be written to the display element specified by your TERM environment variable:
-P asc -o -o -f -o p -z -o 1 -o -p -o 12 -o -s courier -C -N 3 /etc/motd
This is the argument vector generated by this specific instance of the qprt command. If echo had not been mounted over enq, the following job submission command would have been executed:
enq -P asc -o -f -o p -o -z -o 1 -o -p -o 12 -o -s courier -C -N 3 /etc/motd
A job submission command must end with the name of one or more real files that exist in a file system accessible by the AIX operating system. This is true even when the queue is set up to handle jobs other than print jobs.
Note: It is quite important to be sure you execute step 3, otherwise the spooler will be disabled.
When the enq command is executed, either directly or by lp, lpr, or qprt, it assigns a job number to the job. By default, lp will return the job number. lpr and qprt will not return the job number unless you specifically request it with a flag.
enq create a JDF and places it in /var/spool/lpd/qdir. In the later 3.2.x version of AIX, enq writes the name of the JDF to a message queue and signals the qdaemon (by sending it a SIGUSR2) that a new JDF exists. The qdaemon then reads the name of the JDF from the message queue, accesses the JDF directly, and reads the data contained in the JDF into an internal data structure it maintains to track all the jobs currently in the spooler. At this point in time, the job has been accepted by the spooler.
A JDF is created for all spooling system operations other than a queue status query; the structure of a JDF differs between print requests versus job cancellation requests versus queue control requests, and so on, but a JDF is created nevertheless. Commands with the same function as lpstat still call enq to do their work, but neither is a JDF created nor is the qdaemon involved.
In all versions of AIX prior to Version 4, the qdaemon assigns the job a job number when it accesses the JDF and reads its contents into the aforementioned internal data structure. In Version 4, the job number is assigned by enq. This change was made so lp would be compliant with industry standards (lp is supposed to return a job number when the job is submitted, regardless of whether or not the qdaemon accepts the job). This means two things. The first is that the job number of NEW should no longer be seen in Version 4, as the job number NEW only appeared after enq had created the JDF but before the qdaemon had accessed the JDF and assigned a job number. The second is that the existence or absence of a job number can no longer be used to determine if the job has been accepted by the qdaemon.
When the qdaemon determines that the device upon which the job is queued is available, the qdaemon invokes the backend for the queue, passing it arguments specified by the JDF. The backend processes the job.