OpenVMS System Manager's Manual

Information	Description
Summary of the problem	Include the following: The environment in which the problem occurred. For example, does the problem occur only on certain nodes, from certain user accounts, or when using certain layered products? How this problem affects your operations. What site operations are being affected (for example, printing checks or submitting crucial batch jobs)? How often does the problem occur (for example, one printout per month, several printouts per day)? What events occurred on the system between the time the queuing system operated correctly and the time the problem appeared. Any workarounds you are currently using.
Steps for reproducing the problem	Specify the exact steps and include a list of any special hardware or software required to reproduce the problem.
Configuration information	For example: Is the configuration an OpenVMS Cluster system, and does it have multiple system disks? Do you intend the queue database to be located in the default location (SYS$COMMON:[SYSEXE])? Do you intend the master file to be included in a different location than the queue and journal files?
Output from the SHOW QUEUE/MANAGERS/FULL command	Use SYSMAN to enter the command on all nodes, as follows: $ RUN SYS$SYSTEM:SYSMAN SYSMAN> SET ENVIRONMENT/CLUSTER SYSMAN> DO/OUTPUT SHOW QUEUE/MANAGERS/FULL SYSMAN> EXIT $ TYPE SYSMAN.LIS | [Home] | [Comments] | [Ordering info] | [Help] 6017P038.HTM OSSG Documentation 22-NOV-1996 14:22:11.72 Copyright © Digital Equipment Corporation 1996. All Rights Reserved. Legal Type the output file SYSMAN.LIS to verify that the output for all nodes match.
Location of the queue and journal files	If possible, find out the most recent value that was specified in the dirspec parameter of the START/QUEUE/MANAGER command (to specify the location of the queue and journal files). If none was specified, the default is SYS$COMMON:[SYSEXE].
Translation of QMAN$MASTER logical name	Verify that the translation is the same on all nodes. Enter the following commands, and include the resulting output: $ RUN SYS$SYSTEM:SYSMAN SYSMAN> SET ENVIRONMENT/CLUSTER SYSMAN> DO SHOW LOGICAL QMAN$MASTER If the translations returned from the SHOW LOGICAL command are not physical disk names, repeat the SHOW LOGICAL command within the environment of each node to translate the returned value until you reach a translation that includes the physical device name.
Operator log file output	Enter the following commands to search the operator log for any message output by the job controller or queue manager: $ SEARCH SYS$MANAGER:OPERATOR.LOG/WINDOW=5 - _$ JOB_CONTROL,QUEUE_MANAGE On systems with multiple queue managers, for queue managers other than the default, specify the first 12 characters of the queue manager name of any additional queue manager. For example, for a queue manager named PRINT_MANAGER, specify PRINT_MANAGE as follows: $ SEARCH SYS$MANAGER:OPERATOR.LOG/WINDOW=5 - _$ JOB_CONTROL,QUEUE_MANAGE,PRINT_MANAGE
Information returned from relevant DCL commands	Include this information if entering a DCL command shows evidence of the problem.
A copy of the journal file of the queue database	Use the Backup utility (BACKUP) with the /IGNORE=INTERLOCK qualifier to create a copy of the file SYS$QUEUE_MANAGER.QMAN$JOURNAL, and provide this copy to Digital. On systems with multiple queue managers, include copies of journal files for all queue managers. Journal files for queue managers other than the default are named in the format name_of_manager.QMAN$JOURNAL.
Copies of any process dumps that might have been created	Enter the following commands to find any related process dumps, and provide copies of the files to Digital: $ RUN SYS$SYSTEM:SYSMAN SYSMAN> SET ENVIRONMENT/CLUSTER SYSMAN> DO DIRECTORY/DATE SYS$SPECIFIC:[SYSEXE]JBC$*.DMP, - _SYSMAN> QMAN$*.DMP,PRTSMB.DMP,LATSYM.DMP If the problem involves an execution queue using a symbiont other than PRTSMB or LATSYM, also include process dump files from the symbiont. The file name has the format image_file_name.DMP.
Output from the SHOW QUEUE command	If your problem affects individual queues, enter the SHOW QUEUE command to show each affected queue.
Any other relevant information	For example: When was the queue database last created or modified? Was it created or modified since the last reboot of the node or nodes? Does the IPCACP process exist on the affected nodes? If not, try to determine whether the process existed earlier. For example, check the system accounting records.

If you have a printer connected to your system, or if you want to use batch processing, you must use queues. A queue allows users to submit requests for printing or batch processing at any time; the system then prints or processes jobs as resources allow.

Before setting up queues, you need to understand how the queue manager and the queue database operate and how to create them for the OpenVMS queuing system. These are explained in Chapter 12.

Information Provided in This Chapter

This chapter describes the following tasks:

Task	Section
Managing queues on small systems	Section 13.1.1
Designing your batch queue environment	Section 13.2.1
Designing your output queue environment	Section 13.2.2
Planning your queue setup	Section 13.3
Creating and starting queues	Section 13.4
Restarting execution queues on reboot	Section 13.5
Using queue options	Section 13.6
Using and creating forms	Section 13.6.7
Using queue management commands	Section 13.7.1
Managing jobs in queues	Section 13.7.2
Solving queue problems	Section 13.8

This chapter explains the following concepts:

Concept	Section
Queuing process	Section 13.1
Types of queues	Section 13.1.2
Autostart feature	Section 13.1.3
Options for controlling access to queues	Section 13.6.1
Job retention	Section 13.6.2
Queue characteristics	Section 13.6.3
Batch processing options	Section 13.6.4
Job scheduling options	Section 13.6.5
Banner pages	Section 13.6.6
Forms and stock	Section 13.6.7
Page and line overflow	Section 13.6.7.8
Initial form feed	Section 13.6.7.9
Device control libraries	Section 13.6.8

Note

This chapter contains many references to DCL commands. You can find additional information about all DCL commands in the OpenVMS DCL Dictionary.

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 on the queue manager and queue database, and the operation of batch and print queues, including print symbionts, see Chapter 12.

13.1.1 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:

Topic	Section
Simple batch queue configuration	Section 13.2.1.1
Simple output queue configuration	Section 13.2.2.1
Setting up and starting queues	Section 13.3
Choosing and specifying queue options	Section 13.6
Managing queues	Section 13.7.1
Managing jobs in queues	Section 13.7.2

13.1.2 Understanding Classes and Types of Queues

The following sections provide more details about execution and generic queues.

13.1.2.1 Execution Queues

Following are descriptions of types of execution queues:

• 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. (See 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.

Following are descriptions of types of generic queues:

• 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 Section 13.2.1.3).
  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 Section 13.2.2.5).
  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 on setting up a logical queue, see Section 13.7.1.10.

Digital recommends that you use autostart queues whenever possible for a variety of reasons. Autostart queues simplify startup and ensure high availability of execution queues, letting you do the following:

• 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.

Section 13.3 explains these steps in detail.

13.2 Designing Queue Environments

The following sections describe how to design batch queue and output queue environments.

13.2.1 Designing a Batch Queue Environment

You can design batch queues for a single queue, multiple queues, or OpenVMS Cluster environments. Each section referred to in the following table contains figures showing sample configurations to assist you in designing your batch processing environment. Your configuration may combine elements from several of these examples.

Configuration	For More Information
A single queue for limited batch processing	Section 13.2.1.1
Multiple queues for heavy batch processing, or customized queues for specialized batch processing	Section 13.2.1.2
An OpenVMS Cluster environment	Section 13.2.1.3

13.2.1.1 Using a Simple Batch Queue Configuration

You can use this simple configuration, which is suitable for limited batch needs, for a standalone system supporting mainly interactive processing.

Figure 13-1 shows a single, default batch queue.

Figure 13-1 Default Batch Queue

By default, when a user submits a batch job with the SUBMIT command, the job is placed in the queue named SYS$BATCH. To set up a single default queue on a standalone system, name the queue SYS$BATCH.

13.2.1.2 Using Specialized Batch Queues

If your users rely on batch processing or have special processing needs, you might want to set up more than one queue. You can customize batch queues to handle specialized jobs by specifying performance and resource options for jobs in the queue.

Figure 13-2 shows a configuration of several queues, each customized to process certain types of batch jobs.

Figure 13-2 Multiple Batch Queues with Special Resource and Performance Options

In Figure 13-2, SYS$BATCH is the default queue. Normal batch jobs would be submitted to this queue. The FAST queue executes high-priority jobs that should not be swapped out of memory. SLOW is a background queue for processing low-priority jobs. These are large jobs with large requirements for physical memory.

Be conservative when changing base priority and swapping on a queue. Even a slight change can have a significant negative effect on batch and interactive performance. For example, even an increase of 1 in a queue's base priority can affect performance significantly.

For information about specifying these options for a batch queue, see Section 13.6.4.

13.2.1.3 Using Generic Batch Queues in an OpenVMS Cluster Environment

You can use generic queues in a OpenVMS Cluster environment to balance processing resources by distributing batch processing across nodes in the cluster. (For an explanation of generic queues, see Section 13.1.2.)

Figure 13-3 shows a typical configuration.

Figure 13-3 Batch Queue Configuration with Clusterwide Generic Queue

In Figure 13-3, a generic clusterwide batch queue named SYS$BATCH feeds jobs to execution queues on each node in the OpenVMS Cluster environment. A job submitted to SYS$BATCH is placed in the appropriate execution queue to minimize the ratio of executing jobs to job limits for all execution queues fed by SYS$BATCH.

For example, suppose execution queues MOE_BATCH, LARRY_BATCH, and CURLY_BATCH all have a job limit of 5. If MOE_BATCH and LARRY_BATCH are executing four jobs and CURLY_BATCH is executing one job, the generic queue SYS$BATCH feeds the next job to CURLY_BATCH.

See OpenVMS Cluster Systems for more information about OpenVMS Cluster queue configurations. For information about how to create a generic queue, see Section 13.4.3.

13.2.2 Designing an Output Queue Environment

Figure 13-4 shows a simple queue configuration for limited printing needs. This configuration is appropriate for a standalone system supporting a single printer.

Figure 13-4 Simple Output Queue

By default, when a user submits a print job with the PRINT command, the job is placed in the queue named SYS$PRINT. To set up a single default printer queue on a standalone system, name the queue SYS$PRINT.

13.2.2.2 Mixing Printers

If you have several different types of printers (for example, an LN03 printer, an LA210 printer, and an LP27 line printer), you must set up a separate queue for each printer. The options, such as the default form or device control library, that you use with these queues will probably differ according to the printer to which the queue's output is sent. For example, the default form for a line printer might have a width of 132 columns, while the default form for an LN03 printer might have a width of 80 columns.

Figure 13-5 shows such a configuration.

Figure 13-5 Queue Configuration with Mixed Printers

The operating system does not include software to support PostScript printing. To print PostScript files, you must have either of the following:

• A printer capable of printing PostScript files, and supporting software
• Software that provides PostScript-to-sixel printing, and a supported printer

For more information, see your Digital support representative.

13.2.2.4 Using LAT Printers

To share printers among multiple systems or OpenVMS Cluster environments, you can connect printers to a LAT port on a terminal server. Figure 13-6 shows an output queue configuration with a remote printer on a terminal server.

Figure 13-6 Configuration for Remote Printers on a Terminal Server

Digital recommends that you set up your LAT queues as autostart queues with failover lists to ensure that these queues are highly available. Because LAT printers are usually shared among users of multiple systems or clusters, many users will be affected if a LAT queue is unavailable.

For information about how to create autostart queues with failover lists, see Section 13.4.2.

13.2.2.5 Using Generic Output Queues

If you have more than one printer of the same type (for example, if you have three line printers), use generic queues to balance the print load among the printers. Figure 13-7 shows such a configuration.

Figure 13-7 Queue Configuration with Three Like Printers and a Generic Queue

For information about how to create a generic queue, see Section 13.4.3.

13.2.2.6 Using OpenVMS Cluster Queues

Figure 13-8 shows a typical OpenVMS Cluster output queue configuration. For information about OpenVMS Cluster queue configurations, see OpenVMS Cluster Systems.

Figure 13-8 Output Queue Configuration in an OpenVMS Cluster

If your system runs application programs that write output directly to a printer rather than submit it to an output queue, or if you will be using LAT queues, spool your printers. Spooling your printers causes application programs to write output to an intermediate storage device so that the printer remains available to other users while the program is running.