Document revision date: 30 March 2001 | |
Previous | Contents | Index |
Queue characteristics are installation specific. The characteristic parameter can be either a value from 0 to 127 or a characteristic name that has been defined by the DEFINE/CHARACTERISTIC command.
The /NOCHARACTERISTICS qualifier cancels any settings previously established by the /CHARACTERISTICS qualifier for that queue.
If the queue does not have a specified CPUMAXIMUM time limit and the value established in the user authorization file (UAF) has a specified CPU time limit of NONE, either the value 0 or the keyword INFINITE allows unlimited CPU time. If you specify NONE, the CPU time value defaults to the value specified either in the UAF or by the SUBMIT command (if included). CPU time values must be greater than or equal to the number specified by the system parameter PQL_MCPULM. The time cannot exceed the CPU time limit set by the /CPUMAXIMUM qualifier. For information on specifying delta time, refer to the OpenVMS User's Manual or the online help topic DCL_Tips (subtopic Date_Time). For more information on specifying CPU time limits, see Table DCLI-1.
The /CPUMAXIMUM qualifier overrides the time limit specified in the user authorization file (UAF) for any user submitting a job to the queue. Either the value 0 or the keyword INFINITE allows unlimited CPU time. If you specify NONE, the CPU time value defaults to the value specified either in the UAF or by the SUBMIT command (if included). CPU time values must be greater than or equal to the number specified by the system parameter PQL_MCPULM.
For information on specifying delta times, refer to the OpenVMS User's Manual or the online help topic DCL_Tips (subtopic Date_Time). For more information on specifying CPU time limits, see Table DCLI-1.
A CPU time limit for processes is specified by each user record in the system UAF. You also can specify the following: a default CPU time limit or a maximum CPU time limit for all jobs in a given queue, or a default CPU time limit for individual jobs in the queue. Table DCLI-1 shows the action taken for each value specified and possible combinations of specifications.
CPU Time Limit Specified by the SUBMIT Command? | Default CPU Time Limit Specified for the Queue? | Maximum CPU Time Limit Specified for the Queue? | Action Taken |
---|---|---|---|
No | No | No | Use the UAF value. |
Yes | No | No | Use the smaller of SUBMIT command and UAF values. |
Yes | Yes | No | Use the smaller of SUBMIT command and UAF values. |
Yes | No | Yes | Use the smaller of SUBMIT command and queue's maximum values. |
Yes | Yes | Yes | Use the smaller of SUBMIT command and queue's maximum values. |
No | Yes | Yes | Use the smaller of queue's default and maximum values. |
No | No | Yes | Use the maximum value. |
No | Yes | No | Use the smaller of UAF and queue's default values. |
You cannot use the /DEFAULT qualifier with the /GENERIC qualifier.
Possible options are as follows:
[NO]BURST[=keyword] | Controls whether two file flag pages with a burst bar between them are printed preceding output. If you specify the value ALL (default), these flag pages are printed before each file in the job. If you specify the value ONE, these flag pages are printed once before the first file in the job. |
[NO]FEED | Controls whether a form feed is inserted automatically at the end of a page. |
[NO]FLAG[=keyword] | Controls whether a file flag page is printed preceding output. If you specify the value ALL (default), a file flag page is printed before each file in the job. If you specify the value ONE, a file flag page is printed once before the first file in the job. |
FORM=type | Specifies the default form for an output execution queue. If a job is submitted without an explicit form definition, this form is used to process the job. If no form type is explicitly specified with the FORM keyword, the system assigns the form DEFAULT to the queue. See also the description of the /FORM_MOUNTED=type qualifier. |
[NO]TRAILER[=keyword] | Controls whether a file trailer page is printed following output. If you specify the value ALL (default), a file trailer page is printed after each file in the job. If you specify the value ONE, a trailer page is printed once after the last file in the job. |
When you specify the BURST option for a file, the [NO]FLAG option does not add or subtract a flag page from the two flag pages that are printed preceding the file.
For information on establishing mandatory queue options, see the description of the /SEPARATE qualifier. For more information on specifying default queue options, refer to the chapter on queues in the OpenVMS System Manager's Manual.
Enclose strings containing lowercase letters, blanks, or other nonalphanumeric characters (including spaces) in quotation marks (" ").
The /NODESCRIPTION qualifier removes any descriptive text that may be associated with the queue.
PRINTER | Indicates a printer queue. |
SERVER | Indicates a server queue. A server queue is controlled by the user-modified or user-written symbiont specified with the /PROCESSOR qualifier. |
TERMINAL | Indicates a terminal queue. |
If you specify the /DEVICE qualifier without a queue type, the /DEVICE=PRINTER qualifier is used by default.
An output queue is classified as either an execution or generic queue. By default, the /DEVICE qualifier initializes an execution queue of the designated type. To specify a generic printer, server, or terminal queue, use the /GENERIC qualifier with the /DEVICE qualifier.
You specify the queue type with the /DEVICE qualifier for informational purposes. When an output execution queue is started, the symbiont associated with the queue determines the actual queue type. The standard symbiont examines device characteristics to establish whether the queue should be marked as printer or terminal. By convention, user-modified and user-written symbionts mark the queue as a server queue. The device type of a generic queue need not match the device type of its execution queues.
The /DEVICE and /BATCH qualifiers are mutually exclusive; the /NODEVICE and /NOBATCH qualifiers cannot be used together.
If no form type is explicitly specified, the system assigns the form DEFAULT to the queue.
If the stock of the mounted form does not match the stock of the default form, as indicated by the /DEFAULT=FORM qualifier, all jobs submitted to this queue without an explicit form definition enter a pending state and remains pending until the stock of the mounted form of the queue is identical to the stock of the form associated with the job.
If a job is submitted with an explicit form and the stock of the explicit form is not identical to the stock of the mounted form, the job enters a pending state and remains pending until the stock of the mounted form of the queue is identical to the stock of the form associated with the job.
To specify the form type, use either a numeric value or a form name that has been defined by the DEFINE/FORM command. Form types are installation-specific. You cannot use the /FORM_MOUNTED qualifier with the /GENERIC qualifier.
If you do not specify any target execution queues with the /GENERIC qualifier, jobs can be moved to any execution queue that (1) is initialized with the /ENABLE_GENERIC qualifier, and (2) is the same type (batch or output) as the generic queue.
To define the queue as a generic batch or output queue, you use the /GENERIC qualifier with either the /BATCH or the /DEVICE qualifier. If you specify neither /BATCH nor /DEVICE on creation of a generic queue, the queue becomes a generic printer queue by default.
You cannot use the /SEPARATE qualifier with the /GENERIC qualifier.
If the /NAME_OF_MANAGER qualifier is omitted, then the default name SYS$QUEUE_MANAGER is used.
If the INITIALIZE/QUEUE command is used to modify a queue, and that queue is not controlled by the default queue manager, then the name of the controlling queue manager should be specified with the /NAME_OF_MANAGER qualifier. Alternately, the logical name SYS$QUEUE_MANAGER can be defined to be the correct queue manager, making that queue manager the default for the current process.
The /NONO_INITIAL_FF qualifier sends a form feed to the output device to ensure the paper is at the top of a page before printing begins.
The node name is used in OpenVMS Cluster systems; it must match the node name specified by the system parameter SCSNODE for the OpenVMS computer on which the queue executes.
You cannot use the /ON qualifier with the /AUTOSTART_ON or /GENERIC qualifier; however, if you are reinitializing an existing queue, you can specify the /ON qualifier for a queue previously created or started with the /AUTOSTART_ON qualifier. Doing so overrides the /AUTOSTART_ON option and makes the queue a nonautostart queue.
By default, SYS$SYSTEM:PRTSMB.EXE is the symbiont image associated with an output execution queue.
The /NOPROCESSOR qualifier cancels any previous setting established with the /PROCESSOR qualifier and causes SYS$SYSTEM:PRTSMB.EXE to be used.
A null access specification means no access. The default protection is (SYSTEM:M, OWNER:D, GROUP:R, WORLD:S). If you include only one protection code, you can omit the parentheses. For more information on specifying protection codes, refer to the OpenVMS Guide to System Security. For more information on controlling queue operations through UIC-based protection, refer to the chapter on queues in the OpenVMS System Manager's Manual.
ALL (default) | Holds all jobs in the queue after execution. |
ERROR | Holds in the queue only jobs that complete unsuccessfully. |
A user can request a job retention option for a job by specifying the /RETAIN qualifier with the PRINT, SUBMIT, or SET ENTRY command; however, the job retention option you specify for a queue overrides any job retention option requested by a user for a job in that queue.
When the /SCHEDULE=NOSIZE qualifier is in effect, jobs are not scheduled according to size.
If you enter this command while there are pending jobs in any queue, its effect on future jobs is unpredictable.
You cannot use the /SEPARATE qualifier with the /GENERIC qualifier.
The job separation options are as follows:
[NO]BURST | Specifies whether two job flag pages with a burst bar between them are printed at the beginning of each job. |
[NO]FLAG | Specifies whether a job flag page is printed at the beginning of each job. |
[NO]TRAILER | Specifies whether a job trailer page is printed at the end of each job. |
[NO]RESET=(module[,...]) | Specifies one or more device control library modules that contain the job reset sequence for the queue. The specified modules from the queue's device control library (by default SYS$LIBRARY:SYSDEVCTL) are used to reset the device at the end of each job. The RESET sequence occurs after any file trailer and before any job trailer. Thus, all job separation pages are printed when the device is in its RESET state. |
When you specify the /SEPARATE=BURST qualifier, the [NO]FLAG separation option does not add or subtract a flag page from the two flag pages that are printed preceding the job.
For information on establishing queue options that can be overridden, see the description of the /DEFAULT qualifier.
For more information on specifying mandatory queue options, refer to the chapter on queues in the OpenVMS System Manager's Manual.
For autostart queues, this qualifier activates the queue for autostart. The queue begins processing jobs when autostart is enabled with the ENABLE AUTOSTART/QUEUES command on any node on which the queue can run.
The value set by this qualifier overrides the value defined in the user authorization file (UAF) of any user submitting a job to the queue.
Specify the value of n as a number of 512-byte pagelets on Alpha systems or 512-byte pages on VAX. Note that OpenVMS rounds this value up to the nearest CPU-specific page so that the actual amount of physical memory allowed may be larger than the specified amount on Alpha. For further information, refer to the OpenVMS System Manager's Manual.
If you specify 0 or NONE, the working set default value defaults to the value specified in the UAF or by the SUBMIT command (if it includes a WSDEFAULT value).
You also can specify this qualifier for an output execution queue. Used in this context, the /WSDEFAULT qualifier establishes the working set default of the symbiont process for an output execution queue when the symbiont process is created.
For more information about the way a working set default affects batch jobs, see Table DCLI-2.
Specify the value of n as a number of 512-byte pagelets on Alpha or and 512-byte pages on VAX. Note that OpenVMS rounds this value up to the nearest CPU-specific page so that the actual amount of physical memory allowed may be larger than the specified amount on Alpha.
If you specify 0 or NONE, the working set extent value defaults to the value specified in the UAF or by the SUBMIT command (if it includes a WSEXTENT value).
You also can specify this qualifier for an output execution queue. Used in this context, the /WSEXTENT qualifier establishes the working set extent of the symbiont process for an output execution queue when the symbiont process is created.
For more information about the way a working set extent affects batch jobs, see Table DCLI-2.
The value set by this qualifier overrides the value defined in the user authorization file (UAF) of any user submitting a job to the queue.
Specify the value of n as a number of 512-byte pagelets on OpenVMS Alpha or 512-byte pages on OpenVMS VAX. OpenVMS rounds this value up to the nearest CPU-specific page so that the actual amount of physical memory allowed may be larger than the specified amount on OpenVMS Alpha. For further information, refer to the OpenVMS System Manager's Manual.
If you specify 0 or NONE, the working set quota value defaults to the value specified in the UAF or by the SUBMIT command (if it includes a WSQUOTA value).
You also can specify this qualifier for an output execution queue. Used in this context, the /WSQUOTA qualifier establishes the working set quota of the symbiont process for an output execution queue when the symbiont process is created.
Working set default, working set quota, and working set extent values are included in each user record in the system UAF. You can specify working set values for individual jobs or for all jobs in a given queue. The decision table (Table DCLI-2) shows the action taken for different combinations of specifications that involve working set values.
Is the SUBMIT command value specified? | Is the queue value specified? | Action taken |
---|---|---|
No | No | Use the UAF value. |
No | Yes | Use value for the queue. |
Yes | Yes | Use smaller of the two values. |
Yes | No | Compare specified value with UAF value; use the smaller. |
#1 |
---|
$ INITIALIZE/QUEUE/BATCH/START - _$ /AUTOSTART_ON=(DATA::, WARF::, DEANNA::) BATCH_1 |
The INITIALIZE/QUEUE command in this example creates the batch queue BATCH_1, and designates it as an autostart queue capable of executing on node DATA, WARF, or DEANNA. The /START qualifier activates the queue for autostart. The queue will begin executing on the first node (in the list of nodes specified) for which the ENABLE AUTOSTART/QUEUES command is entered.
If the node on which BATCH_1 is executing is taken out of the OpenVMS Cluster, the queue will be stopped on that node and will fail over to the first available node in the node list on which autostart is enabled for a queue manager SYS$QUEUE_MANAGER.
As long as autostart is enabled on one of the nodes in the list, this queue will be started and available to execute batch jobs. If all three nodes in the example are shut down or if autostart is disabled, the queue will remain stopped until one of the three nodes in the node list joins the cluster and executes the ENABLE AUTOSTART/QUEUES command.
The ENABLE AUTOSTART/QUEUES and INITIALIZE/QUEUE commands affect only the queues managed by the default queue manager SYS$QUEUE_MANAGER because the /NAME_OF_MANAGER qualifier is not specified.
#2 |
---|
$ INITIALIZE/QUEUE/START/BATCH/JOB_LIMIT=3 SYS$BATCH $ INITIALIZE/QUEUE/START/BATCH/JOB_LIMIT=1/WSEXTENT=2000 BIG_BATCH |
In this example, the first INITIALIZE/QUEUE command creates a batch queue called SYS$BATCH that can be used for any batch job. The /JOB_LIMIT qualifier allows three jobs to execute concurrently. The second INITIALIZE/QUEUE command creates a second batch queue called BIG_BATCH that is designed for large jobs. Only one job can execute at a time. The working set extent can be as high as 125 pages on OpenVMS Alpha (on a system with 8KB pages) or 2000 pages on OpenVMS VAX.
#3 |
---|
$ INITIALIZE/QUEUE/START/DEFAULT=(FLAG,TRAILER=ONE)- _$ /ON=LPA0: LPA0_PRINT $ INITIALIZE/QUEUE/START/DEFAULT=(FLAG,TRAILER=ONE)- _$ /BLOCK_LIMIT=(1000,"")/ON=LPB0: LPB0_PRINT $ INITIALIZE/QUEUE/START/GENERIC=(LPA0_PRINT,LPB0_PRINT) SYS$PRINT $ INITIALIZE/QUEUE/START/FORM_MOUNTED=LETTER- _$ /BLOCK_LIMIT=50/ON=TXA5: LQP |
In this example, the first three INITIALIZE/QUEUE commands set up printer queues. Both queue LPA0_PRINT and LPB0_PRINT are set up to put a flag page before each file within a job and a trailer page after only the last page in a job. In addition, LPB0_PRINT has a minimum block size of 1000; therefore, only print jobs larger than 1000 blocks can execute on that queue. SYS$PRINT is established as a generic queue that can direct jobs to either LPA0_PRINT or LPB0_PRINT. Jobs that are too small to run on LPB0_PRINT will be queued from SYS$PRINT to LPA0_PRINT.
Previous Next Contents Index
privacy and legal statement 9996PRO_024.HTML