Specifications

4-33
Printer, Plotter, and Spooler Subsystem Programming
pointers to null strings. The print supervisor then calls the sprintf subroutine or a similar
subroutine and passes the nine variable parameter pointers as parameters to the
function.
• The printer backend specifies the correct type (integer or string) for each parameter,
even though all parameters are passed in the pipe as strings. The appropriate type must
be used for handling field width and precision when placing a parameter in an extracted
message.
• The printer backend may or may not pass message catalog information and parameters
for a message. Therefore, the print supervisor must be able to accept the expanded
message itself, or accept the catalog information and parameters and then build the
message accordingly.
Setting Queue States
The qchk command displays the status of a particular device. One of the entries in the table
that is displayed shows the current state of the queue. This information is taken from the
status file. See /usr/include/IN/backend.h in your status file for a list of valid queue states
and their explanation.
Normally, the qdaemon keeps the status file updated. However, some backends may want
to set explicitly the state to WAITING (#include <IN/backend.h>) if they can no longer send
output to the device, and set it back to RUNNING when output resumes. For example, a
backend that paused at the end of each page, waiting for user response, might want to set
the status to WAITING during this time.
The log_status(status) routine can be used to change the status of the job from RUNNING
to WAITING and back again. For more information, see Understanding Backend Routines in
libqb on page 4-34. The parameter is the new status.
In the case of a DEV_WAIT state on a queue device, issue enq –U –Pqueue to attempt to
get the queue to a state of readiness. If this does not work move all the jobs in that queue
and issue enq –G in order to flush the other queues and bring down the qdaemon. Then
restart the qdaemon.
Terminating on Receipt of SIGTERM
When a user cancels a running job with qcan, the command passes the request to the
qdaemon. The backend must stop the print soon after receiving the signal. There are two
ways to accomplish this.
First, the backend cannot do anything special about SIGTERM, in which case the signal
stops the backend process immediately. This option is the simplest, but it does not allow the
backend to do any cleanup (reset line speeds, put paper at top–of–form, hang up the
phone) before it terminates.
Second, the backend can catch SIGTERM, carry out whatever cleanup tasks are required,
and exit EXITSIGNAL (#include <IN/standard.h>). The special exit code tells the
qdaemon that the job was canceled.
Backends that decide to catch SIGTERM should exit very soon after receipt of the signal.