A batch or print
job submitted either by entering the DCL command SUBMIT or PRINT
or through an application is sent to a queue for processing. Information
about the user's queue request, including the type of job, the file
name or names, the name of the queue, and any special options, is sent
to the queue manager. The queue manager stores and retrieves appropriate
information from the queue database to print or execute the job.
The queue manager places the job in the appropriate queue
to await its turn for processing. Only one print job can be printed
on a printer at a single time. However, more than one batch job
can execute simultaneously in a batch queue.
For more information about the queue manager and queue database,
and the operation of batch and print queues, including print symbionts,
see
Managing the Queue Manager and Queue Database.
Managing Queues on Small Systems Many features
available for queues are not required on small systems with minimal
queuing needs (for example, on workstations). If you are managing
a small system, you probably need only the information in the following
sections:
Understanding
Classes and Types of Queues In general, queues can
be divided into two classes:
Class
Description
Execution
queues
Queues that accept batch
or print jobs for processing.
Generic queues
Queues that hold jobs until an appropriate
execution queue becomes available. The queue manager then requeues
the job to the available execution queue.
The following sections provide more details about execution
and generic queues.
Execution Queues Descriptions of types of execution queues follow:
Batch execution queues accept
only batch jobs. A batch job executes as a detached process that sequentially
runs one or more command procedures. The user defines the list of
command procedures when submitting the job.
Output execution queues accept jobs that a symbiont
processes. The queue manager sends the symbiont a list of files,
which the user defines when submitting the job. An output symbiont
transfers data from a disk to an output device. As the symbiont
processes each file, it produces output for the device it controls,
such as a printer or a terminal. The operating system
provides a standard print symbiont named PRTSMB, which prints files
on hardcopy devices. The LAT print
symbiont LATSYM prints files on output devices attached to LAT ports. You
can also design symbionts for this
or any other file-processing activity that the OpenVMS batch and print
queuing system manages. (Refer to the OpenVMS Utility Routines Manual
for
more information.) Output execution queues include the following types:
Type
Description
Printer
execution queue
Uses a symbiont to direct
output to a printer.
Terminal
execution queue
Uses a symbiont to direct
output to a terminal printer.
Server execution
queue
Uses a user-modified or user-written
symbiont to process the files that belong to jobs in the queue.
When you create an output execution queue, you designate it
as either a printer, a terminal, or a server execution queue; you
can also specify the symbiont to be associated with the queue. However,
when the queue is started, the symbiont process associated with
the queue can override the queue designation if the queue type specified
does not match the type of device. The standard symbiont provided with the operating system determines
whether it is controlling a printer or a terminal. The symbiont
communicates this information to the queue manager, which, if necessary, changes
the type designation of the output execution queue. By convention,
a user-written or user-modified symbiont that does not deliver output
to a printer defines its queue as a server queue.
Generic Queues Descriptions of types of generic queues follow:
Generic
batch queues direct jobs only to batch execution queues.
Generic batch queues are typically used in OpenVMS Cluster environments
to distribute the batch work load across several nodes (see
Using Generic Batch Queues in an OpenVMS Cluster Environment). Generic batch queues are not automatically stopped when a
node shuts down. Therefore, they do not need to be started when
a node reboots.
Generic output queues direct
jobs to any of the three types of output execution queues: print,
terminal, or server. Generic output queues are typically used to
distribute the output work load among several like printers (see
Using Generic Output Queues). Generic output queues are not automatically stopped when a
node shuts down. Therefore, they do not need to be started when
a node reboots.
Logical queues are a special
type of generic output queue that transfers jobs to another output execution
queue. You might use a logical queue to temporarily redirect a queue
when the device on which it runs is broken. A logical queue transfers its jobs into the execution queue
specified with the ASSIGN/QUEUE command. For information about setting
up a logical queue, see
Assigning a Logical Queue.
Understanding Autostart Queues HP recommends
that you use autostart queues whenever possible
for a variety of reasons. Autostart queues simplify startup and
ensure high availability of execution queues, allowing you to perform
the following tasks:
With a single command, start all autostart
queues on a node
Specify a list of nodes (in an OpenVMS Cluster environment)
to which a queue can automatically attempt to fail over Autostart failover
is particularly useful on LAT queues. Because LAT printers are usually
shared among users of multiple systems or OpenVMS Cluster systems,
many users are affected if a LAT queue is unavailable. For highest
availability, set up your LAT queues with a list of nodes to which
the queue can fail over, so the queue can continue to run even if
a node becomes unavailable.
To use autostart queues, you must perform the following three
steps:
Task
Description
1
Create the queue as an autostart
queue and, optionally, specify a failover list.
2
Activate the queue for autostart.
You can do this either when you create a queue, or after you create
one.
3
Enable autostart on a node. You can do
this before or after you create a queue.
When you enable
autostart on a node, the queue manager automatically starts all
stopped, active autostart queues capable of running on the node. Any
autostart queue that fails over to the node is also automatically
started.