13.8 Using Queue Options
You can use certain options with your queues. For more
information, see the following sections.
Options Type of queue Section
Most options can be implemented by specifying appropri-
ate qualifiers with the INITIALIZE/QUEUE command when
you create the queue. (You can also specify options after
you create a queue by including qualifiers with the START
/QUEUE or SET QUEUE command.) Table 13-1 lists the
qualifiers you use to specify options for batch queues, and
indicates the type of queue for which you can specify the op-
tion. See the OpenVMS DCL Dictionary for more details about
these qualifiers.
13.8.1 Controlling Access to Queues
As with a file or directory, you can use UIC-based or ACL-
based protection to control access to a queue. See the Security
Guide for detailed information about establishing system
security.
13.8.1.1 Understanding UIC-Based Queue Protection
UIC-based protection restricts the jobs and the users who
have access to a queue. Operations that apply to queues are
controlled by UIC-based protection in the same way that
access to other protected objects (such as files) is controlled.
UIC-BASED Protection
When you create a queue, the queue is assigned an owner
UIC and a protection code. The default owner is [SYSTEM],
but you can specify another owner with the /OWNER_UIC
qualifier. On VAX systems, the default UIC-based protection
for a queue is as follows:
(System:M,Owner:D,Group:R,World:S)
Jobs are assigned an owner UIC equal to the UIC of the pro-
cess that submitted the job, unless the job was submitted with
the /USER qualifier. Each job in a queue, and each operation
that is performed on a queue, is checked against the UIC of
the owner, the protection of the queue, and the privileges of
the requester.
All operations are checked as follows:
Checked against the submit and man-
age protection specified for the queue
and the owner UIC of the queue.
Submit access to a queue allows a user
to submit jobs to that queue. Read
access allows a user to see security
information about a queue. Manage
access allows a user to act as the op-
erator for that queue, with the ability
to affect any jobs in the queue. Users
with operator (OPER) privilege have
manage access to all queues. OPER
privilege also enables users to create
queues and modify security aspects of
queues.
The following table lists each type of access available on VAX
systems, and explains what functions the access controls
when applied to a queue. It also explains the default value
provided on a queue for the access type.
Access Function Default
Owner:Delete-lets users mod-
ify and delete their own jobs.
Read Display attributes of jobs
in a queue
Group:Read-lets users see
the attributes of the jobs of
all users in their UIC group.
Also lets users in the queue's
UIC group see security infor-
mation.
Manage Modify any non-security
attribute of a queue and
delete the queue, plus
submit and read access to
the queue and read and
delete access to all jobs in
the queue
System:Manage-lets users
with a system UIC act as
operators for the queue.
For more information on UIC-based protection, see the
OpenVMS VAX Guide to System Security .
13.8.1.2 Setting and Showing UIC-Based Queue Protection
Use the following commands to set and show UIC-based
protection on queues. For more information on these com-
mands, see the OpenVMS DCL Dictionary .
Command Description
Changes the
default UIC
protection
code on a
queue.
INITIALIZE/QUEUE/OWNER_UIC= uic
START/QUEUE/OWNER_UIC= uic
SET QUEUE/OWNER_UIC= uic
Changes the
owner UIC of
a queue.
SHOW QUEUE/FULL Shows the
protection
currently set
for a queue.
SET SECURITY/CLASS=QUEUE/OWNER= uic Changes the
UIC protec-
tion code on
a queue.
SET SECURITY/CLASS=QUEUE
/PROTECTION= ownership=access
Changes the
default UIC
protection
code on a
queue.
SHOW SECURITY/CLASS=QUEUE Shows pro-
tection cur-
rently set for
a queue.
Examples
1. The following example sets UIC-based protection on a
queue, and then displays information, including security
information, about the queue.
13.8.1.3 Understanding ACL-Based Queue Protection
In addition to UIC-based protection, you can associate access
control lists (ACLs) with a queue. ACL-based protection pro-
vides a more refined level of protection in cases where certain
members of a project group require access to a queue, ex-
cluding others of the same UIC group or of other groups. See
the Security Guide for detailed information about establishing
ACLs for protected objects.
13.8.1.4 Setting and Showing ACL-Based Queue Protection
Use the following commands to set and show ACL-based
protection on queues:
Command Description
Sets
ACL
protec-
tion on a
queue.
SHOW QUEUE/FULL Shows
the
ACLs
set on a
queue, if
any.
y SET SECURITY/CLASS=QUEUE
/ACL=(IDENTIFIER= identifier , ACCESS= access )
On VAX
systems,
sets ACL
protec-
tion on a
queue.
y SHOW SECURITY/CLASS=QUEUE On VAX
systems,
shows
ACLs
set on a
queue, if
any.
For more information on these commands, see the OpenVMS
DCL Dictionary . For more information on ACL-based secu-
rity see the Security Guide .
Examples
1. The SET QUEUE/PROTECTION command in the fol-
lowing example modifies the default UIC-based protec-
tion of queue SYS_QUE1 to prevent access by nonprivi-
leged users. The SET ACL command then restricts access
to only those members of a project group who hold the
ULTRA_LITE or MINUTES identifiers. Members with
the MINUTES identifier have only read and submit ac-
cess to the queue. The SHOW QUEUE/FULL command
displays information, including security information,
about the queue.
$ SET QUEUE/PROTECTION=(S,O,G,W)
$ SET SECURITY/CLASS=QUEUE SYS_QUE1 -
_$ /ACL=((IDENTIFIER=ULTRA_LITE, ACCESS=READ+SUBMIT+MANAGE+DELETE), -
_$ (IDENTIFIER=MINUTES, ACCESS=READ+SUBMIT)) SYS_QUE1
$ SHOW QUEUE/FULL SYS_QUE1
Batch queue SYS_QUE1, stopped
/BASE_PRIORITY=4 /JOB_LIMIT=1 /OWNER=[1,4] /PROTECTION=(S,O,G,W)
(IDENTIFIER=ULTRA_LITE,ACCESS=READ+SUBMIT+MANAGE+DELETE)
(IDENTIFIER=MINUTES,ACCESS=READ+SUBMIT)
2. The following example shows how to use ACLs to restrict
queue access to members of a particular project group:
$ SET QUEUE/PROTECTION=(S,O,G,W)
$ SET ACL/OBJECT_TYPE=QUEUE SYS_QUE1 -
_$ /ACL=((IDENTIFIER=ULTRA_LITE, ACCESS=READ+SUBMIT+MANAGE+DELETE), -
_$ (IDENTIFIER=MINUTES, ACCESS=READ)) SYS_QUE1
3. The following example shows a queue that has only UIC-
based protection, and then gives user AGBELL control
access with an ACL. Control access allows user AGBELL
to modify security information.
$ SHOW SECURITY/CLASS=QUEUE TELEPHONE_QUEUE
TELEPHONE_QUEUE object of class QUEUE
Owner: [INVENTORS,AGBELL]
Protection: (System: M, Owner: MD, Group: R, World: S)
Access Control List: <empty>
$ SET SECURITY/CLASS=QUEUE/ACL=(ID=[AGBELL],ACCESS=CONTROL) TELEPHONE_QUEUE
$ SHOW SECURITY/CLASS=QUEUE TELEPHONE_QUEUE
TELEPHONE_QUEUE object of class QUEUE
Owner: [INVENTORS,AGBELL]
Protection: (System: M, Owner: MD, Group: R, World: S)
Access Control List:
(IDENTIFIER=[CLASS,AGBELL],ACCESS=CONTROL)
13.8.1.5 Understanding How Privileges Affect Queues
Certain account privileges allow users to access a queue in
spite of UIC-based and ACL-based protection. The following
table lists these account privileges and the type of access they
allow on a queue:
Privilege Access
13.8.2 Understanding Job Retention Options
Users can request that a job be retained in a queue after the
job completes by specifying the /RETAIN qualifier when they
submit a job with the PRINT or SUBMIT command.
In addition, you might want to set a job retention policy on
a queue to keep information about all jobs in the queue after
the jobs complete. This might be helpful when an individual
must track jobs submitted by other users.
By default, no job retention policy is set on a queue. To spec-
ify a job retention policy for a queue, use the /RETAIN= option
qualifier with the INITIALIZE/QUEUE, START/QUEUE, or
SET QUEUE command. You can specify one of the following
options:
Option Description
The following command specifies that the queue retain all
jobs that complete with a status other than success:
$ SET QUEUE/RETAIN=ERROR BATCH_QUE
For example, if an operator must be aware of all batch jobs
that do not complete successfully on a certain queue, you
could set the queue to retain jobs that complete with an error
status. This would let the operator enter the SHOW QUEUE
command to display a list of jobs that completed unsuccess-
fully. The SHOW QUEUE display includes the completion
status of jobs retained in the queue. If a job completes un-
successfully, this message can help determine why. The
displays also include the date and time at which a retained
job completed.
If you set a job retention policy on a queue, the queue's
job retention option overrides the job's retention option.
Figure 13-10 shows how job retention affects a job submitted
to a generic queue.
Whether and where a job is retained is determined by the
following:
.
The retention setting on the execution queue in which the
job executes
.
The retention setting on the generic queue (if the job is
submitted to a generic queue)
.
The completion status of the job
.
The retention requested by the user upon submitting the
job (if retention was requested)
If jobs are retained in queues, you should periodically delete
jobs that no longer need to be retained.
Users can specify timed job retention to retain a job only as
long as they need it. For example:
$ SUBMIT/RETAIN=UNTIL=19-MAY-1995:07:31:0.0 MYFILE.DAT
This eliminates the necessity of deleting retained jobs from
queues. If your users make use of the /RETAIN qualifier,
encourage them to use timed retention.
For more information about job retention, see the INITIALIZE
/QUEUE/RETAIN and SUBMIT/RETAIN commands in the
OpenVMS DCL Dictionary .
To remove a job retention option from a queue, specify
the /NORETAIN qualifier with the INITIALIZE/QUEUE,
START/QUEUE, or SET QUEUE command.
13.8.3 Understanding Queue Characteristics
You can define characteristics and assign them to queues to
control the jobs that execute on certain queues.
When users include the /CHARACTERISTIC qualifier with
a PRINT or SUBMIT command, all the characteristics they
specify must also be assigned to the queue that will execute
the job. If a job is placed in a queue that does not have the
characteristics required by that job, the job enters a pending
state. The job remains pending in the queue until you correct
the characteristic mismatch as explained in Section 13.10.2.2.
Users do not need to specify all characteristics of a queue
when they enter a PRINT or SUBMIT command, as long as
the characteristics specified are a subset of those established
for the queue. Similarly, you can define print forms for out-
put queues (including, for example, a specific paper stock and
page format) and assign the forms to queues to control the
jobs that execute on certain queues. For more information,
see Section 13.8.9.
Example
Suppose a system manager manages 12 LN03 printers, with
three printers in each of the four corners of a building. A
generic queue LN03$PRINT feeds execution queues for each
of the LN03 printers. The system manager defines four
characteristics: EAST, WEST, NORTH, and SOUTH. The
EAST characteristic is assigned to the execution queues that
feed printers in the eastern corner of a building. WEST is
assigned to the execution queues feeding the printers in the
western corner, and so on. When a user submits a print job
to LN03$PRINT and specifies the EAST characteristic, the
job prints on the first idle LN03 printer in the eastern corner
of the building.
If the system had queues for printers on multiple floors, the
system manager could further define a characteristic for
each floor, for example, FIRST, SECOND, and THIRD.
13.8.4 Specifying Queue Characteristics Options
To assign characteristics to a queue, specify the /CHARACTERISTICS
qualifier with the INITIALIZE/QUEUE, START/QUEUE, or
SET QUEUE command. You must create a characteristic
with the DEFINE/CHARACTERISTIC command before as-
signing the characteristic to the queue. For more information
on creating and managing characteristics, see Section 13.9.2.
13.8.5 Specifying Batch-Processing Options
You can use queue options to control batch job performance
and the use of system resources by processes executing batch
jobs.
You use the following qualifiers with the INITIALIZE
/QUEUE, START/QUEUE, or SET QUEUE command to
set these queue options:
Option Description
You can also use the following qualifiers. Although these
qualifiers are not specific to batch queues, they are commonly
used like the batch-specific options, to control batch job per-
formance and the use of system resources by batch processes.
Option Description
For more information about these limits, quotas, and priori-
ties, see the following manuals:
.
The INITIALIZE/QUEUE command in the OpenVMS
DCL Dictionary
.
The Guide to OpenVMS Performance Management
By default, a process running a batch job uses values taken
from the UAF record of the user submitting the job or from
system parameter settings. For more information about the
default values for these options, see the description of the
qualifiers for the INITIALIZE/QUEUE command in the
OpenVMS DCL Dictionary . If you specify values for any of
these options, processes for jobs executed in the queue will use
the values you set unless the user specifies values when the
job is submitted. (A user can specify values for CPU time and
for the working set options default, quota, and extent.) If a
user specifies a value for one of these options when the job is
submitted, this value cannot exceed the value you set for the
queue. If you did not specify a value, the value specified by
the user cannot exceed the value specified in the associated
UAF limit or system parameter.
The following sections provide guidelines for choosing values
for these options.
For More
Information
13.8.5.1 Base Process Priority
Choose a value based on how quickly you will allow batch
jobs to progress. If you choose a value equal to the system
parameter value DEFPRI (typically 4), jobs in this queue
will progress at the same rate as typical interactive jobs.
This choice might be appropriate for systems that have an
abundance of available CPU time.
If, on the other hand, you choose a value less than DEFPRI,
jobs in this queue will potentially progress more slowly than
the typical interactive job. CPU time will be allocated to jobs
in this queue only after servicing jobs of DEFPRI priority.
In the case of a queue defined for a very special purpose-for
example, high- priority jobs-a value greater than DEFPRI
(for example, 5) might be appropriate. However, this choice
can have a significant negative effect on the performance of
other users and batch jobs.
13.8.5.2 Job Limit
Keep this value low when using a base process priority of
DEFPRI or greater, since each batch job can affect the per-
formance of interactive jobs.
13.8.5.3 Working Set Default, Quota, and Extent
If you do not specify values for these options, a job uses the
value specified in its owner's user authorization file (UAF)
record.
Process Limit Description
In general, the working set quota and extent values specified
in the UAF record for each user are sufficient. However, you
might want to specify more generous or stringent values for
a queue, depending on the purpose of the queue. For exam-
ple, you might encourage users to submit large jobs (such as
compiling and linking large programs) as batch jobs to re-
serve interactive use of the system for jobs that do not require
extensive resources, as follows:
.
Set a large working set size for batch jobs by specifying
larger WSQUOTA and WSEXTENT values when you
create the batch queue.
.
Restrict the working set size of interactive jobs by pro-
viding smaller WSQUOTA and WSEXTENT values in
users' UAF records.
13.8.5.4 CPU Default and Maximum
You can restrict and expand the amount of time a job is
allowed in the CPU by setting CPU limit values.
Be careful to not set CPU time limit values too low. When a
job's CPU time limit is exceeded, the job is terminated with an
error status. If working set values (explained in the previous
section) are set too low, the system might use memory less
efficiently but the jobs can still complete normally. However,
if CPU time limit values are set too low, the system might
terminate jobs that are making legitimate and authorized use
of the CPU.
For example, you might use a CPU time limit on a batch
queue devoted to execution of newly coded software that could
unexpectedly enter a CPU loop. The CPU time limit would
terminate infinitely looping jobs so they do not waste the CPU
resource. However, you must be careful to choose a suf-
ficiently high time limit so normally executing jobs do not
terminate prematurely.
Another way to control allocation of the CPU resource is to
create a special-purpose batch queue that shifts execution of
its jobs to a less busy time of day when CPU time is more
available.
13.8.5.5 Swapping
Typically, swapping is enabled on batch queues. However,
for a very special-purpose, high-priority queue, you might
disable swapping. This provides a favorable status to jobs
in this queue by removing them from consideration when
memory must be reclaimed from processes (through the op-
erating system's swapping and trimming mechanism). For
more information, see the Guide to OpenVMS Performance
Management .
13.8.5.6 Setting Up Batch Queues on Memory-Constrained
Systems
On memory-constrained systems, you should add up the
pages required for the batch working sets on all batch queues
and make sure that enough fluid memory remains for inter-
active jobs. Fluid memory can be reassigned from one process
to another through swapping and paging. (You can calculate
fluid memory as the space that remains when you subtract
the number of pages permanently allocated to the operating
system from the total memory. To obtain these values, enter
the DCL command SHOW MEMORY.)
13.8.5.7 Optimizing Batch Queues for the Sort/Merge Utility
You can improve the efficiency of the OpenVMS Sort/Merge
utility (SORT/MERGE) by designating one batch queue for
sorting jobs and giving this queue a very large working set
quota.
In addition, you can set process quotas for greatest SORT
efficiency. The values recommended here are based solely
on SORT considerations; you should integrate other system
considerations with these to determine appropriate values.
.
Working set extent per process (WSEXTENT)-For max-
imum sorting efficiency, use the /WSEXTENT qualifier
with the INITIALIZE/QUEUE, START/QUEUE, or SET
QUEUE command to set this value on the queue to the
largest value any sorting job would ever need. Generally,
the smaller the working set, the slower the sort.
For very large files, working sets of 4000 or more pages
(on VAX systems) or pagelets (on Alpha systems) are not
unreasonable, provided the system has enough physical
memory to support them.
.
Virtual page count per process (VIRTUALPAGECNT
system parameter)-For maximum sorting efficiency, set
this system parameter to at least 1000 pages (on VAX
systems) or pagelets (on Alpha systems) more than the
maximum working set extent. Although SORT limits the
size of the sort data structure to the process's working set
extent, if work files are required, SORT can use the extra
memory for I/O buffers. If this parameter is too low rel-
ative to the working set extent, SORT might be unable to
create buffers for the work files when the files cannot be
sorted in memory.
13.8.6 Specifying Job Scheduling Options
For output queues, you can choose options that control how
the size of a print job affects its scheduling. Specify the fol-
lowing qualifiers with the INITIALIZE/QUEUE, START
/QUEUE, or SET QUEUE command to control print job
scheduling:
Option Description
For more information on job scheduling, see Section 13.9.6.4.
/BLOCK_LIMIT
By default, printer and terminal queues are created with no
block limit, so jobs of any size will be printed. However, you
can specify the /BLOCK_LIMIT qualifier to limit the size of
jobs that can be printed. You can specify just an upper limit
or both an upper and lower limit.
For example, you could submit a batch job that runs a com-
mand procedure to set a maximum block limit of 500 blocks
for a queue at 8:00 a.m. The command procedure might re-
submit itself and remove the block limit after 5:00 p.m. each
day. This would let users print jobs of any size after normal
work hours, when the printing work load is lighter. Users
can specify the /AFTER qualifier with the PRINT qualifier to
specify that a job is to be printed after a certain time.
For more information about restricting print job sizes, see
the /BLOCK_LIMIT qualifier for the INITIALIZE/QUEUE,
START/QUEUE, or SET QUEUE command in the OpenVMS
DCL Dictionary .
13.8.7 Understanding Banner Pages
You should understand the following terms:
Term Definition
Most sites use only a subset of the available banner pages
at any given time. The following table describes the types of
banner pages you can use:
For
More
Information
Figure 13-11
Trailer page A page printed after each job. Figure 13-13
Figure 13-12
Burst page Two flag pages, divided by a separation
(burst) bar, printed before each file in a job.
Figure 13-12
Trailer page A page printed after each file in a job. Figure 13-14
13.8.7.1 Flag and Burst Pages
Flag and burst pages both indicate that a print file follows.
However, a burst page is two flag pages divided by a burst
bar , which is designed to print over the crease between two
pages of continuous-form paper. The burst bar is used for
ease in separating continuous-form paper. If you do not
need to burst pages of a printer's output-for example, if your
printer uses cut sheet paper-avoid the burst page option.
Flag pages, or flag and trailer pages, are usually sufficient for
identifying the end of a job.
Figure 13-11 illustrates job flag and burst pages produced by
the default print symbiont, PRTSMB.
Figure 13-12 illustrates file flag and burst pages produced by
PRTSMB.
The job flag page indicates that a new job follows; the job can
include one or more files. Information found on a job flag
page includes the following:
TABLE: Click to display Table.
Figure 13-12 illustrates a file flag and burst page.
13.8.7.2 Trailer Pages
A trailer page indicates the end of a print job or print file.
Figure 13-13 illustrates a job trailer page. Figure 13-14
illustrates a file trailer page.
The job trailer page indicates the end of a print job.
Information found on the job trailer page includes the fol-
lowing:
TABLE: Click to display Table.
The file trailer page includes the following items:
TABLE: Click to display table.
Widths greater than 40 characters and less than 200 char-
acters and lengths of any size greater than 40 characters
are supported for file and job banner pages. Pages requested
for widths greater than 200 characters are formatted and
printed at 200-character widths. Lengths less than 40
characters are extended by that form length until the 40-
character threshold is exceeded. Margins are not taken into
account when formatting banner pages.
13.8.8 Specifying Banner Page Options
You specify banner page options by including the following
qualifiers with the INITIALIZE/QUEUE, START/QUEUE, or
SET QUEUE command:
Page Type Qualifier
/DEFAULT= option = keyword
Where option can be one or more of
the following:
[NO]BURST
[NO]FLAG
[NO]TRAILER
Keyword can be either ALL or ONE.
13.8.9 Understanding Forms
Print forms serve the following functions:
.
Forms determine certain page formatting attributes (such
as margins and page length).
.
The paper stock specified in the form definition is used in
determining whether a job is eligible to print.
If your printing needs are limited, using special forms is not
necessary; Digital supplies a systemwide default form (named
DEFAULT) for all queues.
However, if you want to help users format output or if cer-
tain print jobs require special paper, you can create one or
more forms. Users can then request a form for a print job
by specifying the form when they submit a job. If a user does
not specify a form, the job uses the queue's default form .
See Section 13.9.4.4 for information about specifying a default
form for a queue.
You can create forms to format output in the following ways:
For
More
Information
Section 13.9.4.1
Specify that a certain paper stock must be physically loaded in
the printer.
Section 13.9.4.1
Specify device control library modules to set up the device at
the start of each page or each file, or both.
The stock of a form is particularly important because it af-
fects whether a job is eligible to print. The stock of a job's
form must match the stock of the form currently being used
by the queue (the queue's mounted form ), or the job will not
be scheduled to print; instead, it remains pending in the queue
until you perform special steps. (These steps are described in
Section 13.10.2.1.)
A queue's mounted form is the form of the current job or,
if no job is processing, the form of the last job printed in a
queue. As long as the stock of a job's form matches the stock
of the queue's mounted form, the job is processed using the
options in the job's form, and the mounted form changes
automatically to the form of the job being processed in the
queue.
13.8.10 Specifying Forms Options
To use forms with your queues, take the following steps:
1. Create a form using the DEFINE/FORM command as
explained in Section 13.9.4.1.
2. If you want to change the DEFAULT form, do so before
creating any queues that reference the DEFAULT form.
For more information, see Section 13.9.4.3.
3. Assign a default form for each output execution queue. To
assign a default form, specify the /DEFAULT=FORM= form-
name qualifier with the INITIALIZE/QUEUE, START
/QUEUE, or SET QUEUE command. For more infor-
mation, see Section 13.9.4.4.
If you do not assign a default form to a queue, the queue
uses the systemwide default form, DEFAULT.
4. Inform users of the available forms and the queues with
which they should be used.
For information on creating and managing forms, see
Section 13.9.4.
13.8.11 Specifying Options for Controlling Page and Line
Overflow
Under certain conditions, lines and pages formatted by the
print symbiont might exceed the length of lines and pages for
a printer. You can use queue options to control line and page
overflow.
13.8.11.1 Controlling Line Overflow with Forms
Digital recommends that you control line overflow by us-
ing form definitions. To do this, you must set terminals and
printers to avoid wrapping or truncating the print line before
the physical limit of the device's width.
Different forms can have different right, left, top, and bot-
tom margin settings. By using forms to control page and line
overflow, users can switch from one form to another with-
out requiring operators to stop the queue, alter the device
setup, and restart the queue. The queue manager auto-
matically mounts any forms with the same stock as the
currently mounted form. Operator assistance is needed only
to mount a form that has a stock that differs from the stock
of the currently mounted form. For more information, see
Section 13.10.2.1.
To control line overflow, create forms using the DCL com-
mand DEFINE/FORM and specify the following qualifiers:
Qualifier Function
For more information on creating and managing forms, see
Section 13.8.9.
13.8.11.2 Controlling Page Overflow with the Form-Feed Character
To control page overflow errors, specify the /DEFAULT=[NO]FEED
option with the INITIALIZE/QUEUE, START/QUEUE, or
SET QUEUE command. This option controls whether a
form-feed character is automatically inserted when the
symbiont detects overflow into the bottom margin area. Users
can use the PRINT/FEED or PRINT/NOFEED command to
override the default feed option specified for a queue.
Users can specify the /PASSALL qualifier with the PRINT
command to bypass all formatting performed by the print
symbiont. The default is /NOPASSALL. This qualifier
should be used in cases where the print symbiont format-
ting might interfere with the desired formatting of the file.
The /PASSALL qualifier causes the print symbiont to send
I/O to the device driver with all formatting suppressed and to
behave as follows:
.
Not interpret Fortran or print carriage control characters
.
Not perform line or page overflow error handling
.
Not interpret escape sequences
13.8.12 Understanding Device Control Libraries
A device control library is a text library that contains user-
written modules consisting of text or escape sequences. Device
control library modules can be used for the following pur-
poses:
.
With programmable printers, to insert device-dependent
escape sequences that set up a printer for selected print
options such as point size, character set, and bold or italic
print
.
With both programmable and nonprogrammable print-
ers, to insert text at specific points in the processing of a
print job
The three types of device control modules, distinguished by
their placement in a print job, are:
Module Type Placement
Inserted at the beginning of each page.
RESET modules Inserted at the end of each job. Use reset
modules to reset a printer to a known state at
the end of a job.
13.8.13 Specifying Device Control Library Options
To specify a setup or page setup module for a queue, use
forms. Create one or more forms with the DEFINE/FORM
command, and specify the /SETUP= module or /PAGE_
SETUP= module qualifier to specify the module to be used.
When the form is used with a print job, the module will
automatically be sent to the printer.
To specify a reset module, use the /SEPARATE=RESET= module
qualifier with the INITIALIZE/QUEUE, START/QUEUE, or
SET QUEUE command. The module will be automatically
sent to the printer at the end of every job.
To use device control library options, perform the following
steps:
1. Create a library and insert modules.
2. Assign the device control library to a queue. (This step
is not necessary if you use the default library name
SYSDEVCTL.TLB.)
3. Create one or more forms with setup or page setup
modules.
4. Assign reset modules to a queue.
For more information on creating and managing device
control libraries, see Section 13.9.5.
13.8.14 Understanding the Order of Device Control
Module Output
The following list shows the order in which device control
modules are sent to the printer within a print job:
1. Reset modules assigned to the queue. (Reset modules are
only used at this point for the first job printed after a
queue is started.)
2. Setup modules specified in the form definition.
3. Page setup modules specified in the form definition.
4. Setup modules specified with the PRINT command
5. Page 1 of file 1.
6. Page setup modules specified in the form definition.
7. Page 2 of file 1, and so forth.
8. Page setup modules specified in the form definition.
9. Last page of file 1.
10. Setup modules specified in the form definition.
11. Page setup modules specified in the form definition.
12. Setup modules specified with the PRINT command.
13. Page 1 of file 2.
14. Page setup modules specified in the form definition.
15. Page 2 of file 2, and so forth.
16. Page setup modules specified in the form definition.
17. Last page of file 2.
18. Reset modules assigned to the queue.