The name of the standard device control library is DCPS$DEVCTL. This is the default library name if this parameter is blank. Refer to Chapter 7 for more information about creating device control libraries and defining the device control library logical name.

3.3.4 Assigning Default PRINT Command Parameters to the Queue (P4)

You can specify default PRINT command parameters to associate with the queue. Any PRINT parameter can be associated by default with a queue. Default PRINT parameters are used when the print job prints on the specified queue, unless the user specifies different parameter values in the PRINT command line. The parameter values specified in the PRINT command line override the default queue parameters.

Place quotes around default PRINT parameters, as shown in the following example:

$ @SYS$STARTUP:DCPS$EXECUTION_QUEUE - 2UP - ! P1 - Execution queue name "SERIAL/TTB4:" - ! P2 - Interconnect protocol/Device name DCPS_LIB - ! P3 - Logical name for library(ies) "SIDES=2" ! P4 - Default queue parameters

How DECprint Supervisor Prioritizes PRINT Parameters

Parameters set by the /PARAMETERS qualifier of the PRINT command override any defaults set for the queue. DECprint Supervisor uses default values for parameters, from highest to lowest priority, as follows:

1. Parameters specified in the PRINT command
2. Queue defaults specified for the generic queue
3. Queue defaults specified for the execution queue
4. Defaults built into the DCPS software:

   DATA_TYPE=AUTOMATIC
   INPUT_TRAY=printer-specific¹
   LAYUP_DEFINITION=no default layup definition
   MESSAGES=NOMESSAGES
   NUMBER_UP=0
   OUTPUT_TRAY=printer-specific¹
   PAGE_LIMIT=no limit
   PAGE_ORIENTATION=PORTRAIT
   PAGE_SIZE=(same as SHEET_SIZE)
   NOPUNCH
   SHEET_COUNT=1
   SHEET_SIZE=printer-specific¹
   SIDES=printer-specific¹
   STAPLE=NONE
   TAB=NOTAB

Some parameter values are controlled by the printer hardware and can be set through means other than the DECprint Supervisor software. DIGITAL PrintServer printers are affected by the PrintServer Software. Other printers are controlled through the printer control panel or switches.

3.3.5 Supplying Default Queue Attributes (P5)

You can supply a value to override or add to the default queue attributes. Do not use the INITIALIZE/QUEUE command to set these qualifiers. Enter them into the queue definition instead.

By default, the printer startup command procedure creates print queues with the following INITIALIZE/QUEUE qualifier settings:

• /SEPARATE=(BURST,TRAILER,NORESET)
  The /SEPARATE qualifier is used to specify job separation pages. The default setting specifies:
  • Job burst pages.
  • Job trailer pages.
  • No reset module is sent between print jobs (NORESET). This setting is included for compatibility with sites upgrading from PrintServer client software.
• /FORM_MOUNTED=DCPS$DEFAULT
  This qualifier allows you to include a default form definition assumed to be mounted on the printer. The default form for ANSI jobs only is DCPS$DEFAULT. If you include a form definition with the /FORM_MOUNTED qualifier, specify the same form definition in the /DEFAULT qualifier as well.
• /DEFAULT=(NOFEED)
  The /DEFAULT qualifier specifies default PRINT qualifiers. The standard queue definition specifies a default setting of NOFEED on print jobs. You can modify this command line to include any PRINT qualifiers. For example, you can include your own form to be applied to print jobs when a form definition is required:

  /DEFAULT=(FORM=MYFORM,NOFEED)

  
  If you specify the /DEFAULT qualifier, be sure to include the FORM and NOFEED keywords. If they are not included, the values revert to the OpenVMS defaults, which are not compatible with the DECprint Supervisor software.

You can set the communications speed for serial printers attached directly to your OpenVMS system. If this parameter is blank, the default is 9600 baud. To change the speed, replace the null string ("") with a value, such as "19200". For printers that utilize network connections, this parameter is ignored.

3.3.7 Supplying SET DEVICE Qualifiers to the Queue (P7)

You can specify the SET DEVICE command qualifiers for this queue. For example, to enable error logging, include the following string:

"/ERROR_LOGGING"

Now, all error messages reported by the printer are recorded in the error log file, SYS$ERRORLOG:ERRLOG.SYS. You can read this file using the ANALYZE/ERROR command.

This parameter is valid for serial printers only.

3.3.8 Enabling SET VERIFY When Initializing the Queue (P8)

You can specify the setting of the SET VERIFY command for the DCPS$EXECUTION_QUEUE.COM command procedure. The default setting is NOVERIFY, to save log file space and console log space. If P8 contains 1, then SET VERIFY is enabled, which is useful for diagnosing problems in the printer startup file. (Refer to the OpenVMS DCL Dictionary for more information about the SET [NO]VERIFY command.)

3.4 Running the Startup Procedure in Setup Mode

The DCPS startup procedure, DCPS$STARTUP, can be run in a shortened "setup" mode. This mode would most commonly be used if your queues are autostart queues, and you wanted to speed up the execution of DCPS$STARTUP. In setup mode, logical names needed by DCPS are defined, but no queues are created, modified or started.

To run DCPS$STARTUP in setup mode, pass SETUP as the P1 parameter. For example,

$ @SYS$STARTUP:DCPS$STARTUP SETUP

To define logical names, DCPS$STARTUP now creates a "setup file" each time it runs in normal (non-setup) mode. This file is called DCPS$STARTUP_SETUP.COM and is run when DCPS$STARTUP is later run in setup mode. The setup file should not be modified and is only for use by DCPS$STARTUP.

Please note the following details concerning setup mode:

• When run in setup mode, all commands in DCPS$STARTUP.COM are executed, except for initializing or modifying queues with calls to DCPS$EXECUTION_QUEUE and DCPS$GENERIC_QUEUE. All other code, such as creating LAT devices or defining queue-related logical names such as DCPS$queuename_NO_SYNC will be executed.
• If the setup file does not exist when DCPS$STARTUP is run in setup mode, startup will run in normal mode and a setup file will be created.
• DCPS$STARTUP will display whether it is running in setup or normal mode.
• If running in setup mode, DCPS$STARTUP will display the creation date of the setup file it is using.
• If running in setup mode, and DCPS$STARTUP.COM has been modified since the setup file was created, an informational message will be displayed. Startup will continue in setup mode, ignoring changes to the procedure made in the portion of DCPS$STARTUP that does not run in setup mode. In this case, DCPS$STARTUP.COM should be reviewed to see if any changes affecting queues were made, and run again in normal mode so a new setup file can be created.
• To use DCPS$STARTUP in setup mode, you must copy the new DCPS$STARTUP.TEMPLATE to DCPS$STARTUP.COM and incorporate your site-specific modifications.

You can alter the behavior of DCPS print symbionts and their corresponding execution queues in a number of ways, several of which are described in this section. Other options are listed in Appendix B, along with general guidelines for making the changes. Some customizations apply to all DCPS queues while others apply only to queues that you specify.

3.5.1 Running DCPS as a Multistreamed Process

DECthreads is used to implement the numerous functions of DCPS. All processes that use DECthreads execute periodically to determine if any threads can run. Even when no jobs are printing, DECthreads causes a DCPS process to run to determine if any threads can run. If there are many DCPS queues started on a system, the scheduling and periodic execution of all these processes can use a significant amount of CPU time. This problem is resolved by running DCPS as a multistreamed process, thereby reducing the number of symbiont processes that must execute.

When running multistreamed, one DCPS process can run more than one DCPS execution queue. A new DCPS process is not started every time a DCPS print queue is started, but only when all current processes are supporting a specified maximum number of queues ("streams"). The number of queues that a DCPS symbiont process will support is determined by the value of the logical name DCPS$MAX_STREAMS when the process is started.

DCPS can be configured to support up to 32 execution queues per DCPS symbiont process. The logical name DCPS$MAX_STREAMS is used to specify the number of queues per DCPS symbiont process. To define this logical, specify the following command in your DCPS$STARTUP.COM file (a template is provided in DCPS$STARTUP.TEMPLATE) and substitute the number of queues per process to use. If this logical name is not defined, a DCPS process will support only one (1) execution queue.

$ DEFINE /EXECUTIVE_MODE /SYSTEM DCPS$MAX_STREAMS max-number

Execute your DCPS$STARTUP.COM file to define this logical name and start your queues with DCPS as a multistreamed process.

A DCPS process terminates only when all queues associated with the process are stopped.

3.5.1.1 Managing Print Queues When Running Multistreamed

The OpenVMS Queue Manager controls when a symbiont process is created and terminated. Generally a new DCPS symbiont process is created when there are no free streams in all existing DCPS symbiont processes.

The set of print queues that a DCPS symbiont process supports is determined by the order in which queues are started, and by any subsequent stopping ( STOP /QUEUE /RESET or STOP /QUEUE /NEXT ) and starting ( START /QUEUE ) of queues. DCPS defines a logical name which identifies the process ID for a queue ( Section 5.8). You can use these logical names to determine the process that supports a queue and the set of queues that are supported by the same process.

Although not likely, a problem observed with one queue could be the result of a problem that exists with another queue, because both queues are supported by the same process. It may not be sufficient to examine the state of one job on one queue to identify a problem. You may need to look at the state of the first job on all the queues supported by that DCPS process.

A DCPS queue should not be stopped by stopping the DCPS process that supports that queue. Stopping a DCPS symbiont process with STOP /IDENTIFICATION will stop all of the queues supported by that process.

3.5.1.2 Changing the DCPS Environment When Running Multistreamed

With a single-streamed DCPS symbiont process, changes to DCPS logicals names and other aspects of the DCPS environment may not take effect until after you have issued a STOP /QUEUE /RESET and then a START /QUEUE command for the associated queue, depending on what you are trying to change.

To change the behavior for a single DCPS queue that is associated with a multistreamed process, you may need to stop all the DCPS queues associated with that symbiont process and then restart them before the change will take effect. This is because some aspects of the environment are determined only when the DCPS symbiont process starts (rather than when a DCPS queue starts) and the symbiont process does not stop until all of its associated queues are stopped.

3.5.1.3 Determing the Proper Value for DCPS$MAX_STREAMS

There are several factors to consider to determine an appropriate number of queues per DCPS symbiont process including:

• You can reduce the number of process slots taken by DCPS by increasing the number of queues per process. This will free up process slots. By reducing the number of DCPS symbiont processes, you reduce the number of DECthread processes that must run periodically, which improves system performance.
• Even though a DCPS process can be configured to support more than one execution queue, DCPS can translate only one file at a time. To avoid contention for translators, when a stream (queue) in a process needs a translator that is already in use, the translator for that stream is started in a separate temporary process. This can impact performance if your site primarily uses one translator, and print queues are generally busy. To reduce the likelihood of a impact on performance, choose a smaller value for DCPS$MAX_STREAMS.
• The maximum number of queues per process is 32. This limit is imposed by the OpenVMS queue manager.
• A DCPS process running multiple print queues represents a potential single point of failure. If the supervisor process fails, or someone stops the process, then several queues are affected.

DCPS normally waits for a raw TCP/IP, LAT, or serial printer to be idle before sending a new job to it. This is especially important in a networked environment where a printer connected through a DECserver device or other network terminal server can be shared among DCPS queues, LATSYM queues, Windows and UNIX hosts, etc.

Prior to version V1.2, DCPS used an aggressive synchronization sequence to gain control of a printer's PostScript interpreter. This scheme worked well in an all-DCPS environment, but in a multi-host environment it sometimes caused print jobs from other systems to terminate prematurely.

If you rely on DCPS's earlier behavior to abort errant PostScript jobs on one queue by starting a job on another queue, you can define the following system logical name to restore the more aggressive behavior:

$ DEFINE /EXECUTIVE_MODE /SYSTEM DCPS$queuename_INTERRUPT_WHEN_BUSY TRUE

3.5.3 Suppressing PostScript Synchronization When a Job Starts

DCPS begins a job on a raw TCP/IP, LAT, or serial printer by synchronizing with its PostScript interpreter to ensure that the interpreter is ready to accept commands. However, some PostScript printers are not always in a state where they can recognize the synchronization control characters. In particular, some printers that support additional printer languages like PCL do not correctly respond to this sequence under certain circumstances. For example, the DEClaser 3500, when in PS/PCL sensing mode, inadvertently switches to PCL mode when DCPS sends a Ctrl/T character to its serial port. The printer, then out of the PostScript mode, does not respond, and the print job gets stuck in the "starting" state.

You can define a logical name to cause the DCPS symbiont to avoid using its usual synchronization sequence for printers that use a raw TCP/IP, LAT, or serial connection. The logical name has no effect when using printers connected via other means. Refer to Chapter 10 for printer-specific recommendations.

To disable the synchronization sequence for a print queue, use the following command:

$ DEFINE /EXECUTIVE_MODE /SYSTEM DCPS$queuename_NO_SYNC TRUE

The absence of the synchronization step is not generally a problem for most modern serially-connected printers because such printers use flow control to hold off data when the interpreter is not ready to accept data. However, the printer is more vulnerable to printing "garbage" or losing jobs if communication parameters, such as baud rate and stop bits, are not set correctly. Depending on the configuration, it's also possible to lose print jobs if the printer data cable is disconnected or the printer is powered off.

3.5.4 Purging the Symbiont Process's Working Set

The DCPS symbiont purges its working set after it has been idle for a period of time in order to conserve system resources. The time delay is intended to help prevent the system from thrashing by keeping the program in physical memory while more work is apt to arrive.

By default, DCPS waits ten (10) minutes after becoming idle before purging its working set. You can increase this value, if desired, by defining a system-wide logical name:

$ DEFINE /EXECUTIVE_MODE /SYSTEM DCPS$PURGE_TIME "0 hh:mm:ss.00"

where hh:mm:ss.00 is an OpenVMS delta-time value specifying the desired time delay. If the value is less than the default of ten seconds, the default is used.

3.5.5 Suppressing the OPCOM Message USERNOTFOUND

If DCPS is running on an OpenVMS cluster that has more than one User Authorization file (UAF), it is possible the user submitting a print job does not have a UAF record on the system running the DCPS queue. DCPS prints the job but issues a USERNOTFOUND operator message:

%%%%%%%%%%% OPCOM 1-JAN-2003 18:43:55.87 %%%%%%%%%%% Message from user SYSTEM on LITERA Queue SHARIE: %DCPS-W-USERNOTFOUND, user name FOO not found, no log files created -RMS-E-RNF, record not found

Because the username cannot be found, DCPS cannot perform the MESSAGES=KEEP or MESSAGES=PRINT parameter request.

To prevent this OPCOM message from being displayed for every job, define one of the following logical names, depending on whether you want the message suppressed for one print queue or all queues:

$ DEFINE /EXECUTIVE_MODE /SYSTEM DCPS$queuename_IGNORE_UNKNOWN_USER TRUE $ DEFINE /EXECUTIVE_MODE /SYSTEM DCPS$IGNORE_UNKNOWN_USER TRUE

3.5.6 Using Old ANSI Translator Page Size for A4 Landscape

All versions of the ANSI translator prior to DCPS V1.1A had a problem printing 66 lines of text in landscape mode on A4 paper. Certain printers have slightly smaller than average print areas when using A4 paper, which resulted in the 66th line being lost or clipped when using print parameters of PAGE_SIZE=A4,PAGE_ORIENTATION=LANDSCAPE .

The ANSI translator now correctly prints 66 lines of text in landscape mode on A4 paper. The fix involved changing the vertical spacing of the font used (SGR 15) and correcting the maximum printable area for A4 paper.

If you use preprinted forms that depend on the old translator's behavior, you can retain the old behavior by defining a DCPS logical name:

$ DEFINE /EXECUTIVE_MODE /SYSTEM DCPS$queuename_OLD_ANSI_PAGE_SIZES TRUE

3.6 Setting Up Generic Queues

Generic queues are not associated with a specific printer; rather, they point to the execution queues. Generic queues can be associated with more than one execution queue and can distribute print jobs among queues, or they can be used to associate specific DECprint Supervisor functions with a print job. Generic queues are optional.

Example 3-4 shows how to set up a generic queue for printing with a layup definition file. This generic queue feeds print jobs to either of two ScriptPrinter execution queues.

Example 3-4 Setting Up a Generic Queue

$ @SYS$STARTUP:DCPS$GENERIC_QUEUE - DRAFT_DOCS - ! P1 - Generic queue name "LN03R_TTB4,LN03R_TTB7" - ! P2 - Execution queue name(s) "LAYUP=LPS$SINGLEHOLES" ! P3 - Default queue parameters

Table 3-3 Parameter Values for Generic Queues

Parameter	Value
P1 (required)	Name of the generic queue. In Example 3-4, DRAFT_DOCS is the generic queue to which users will send print jobs.
P2 (required)	Name of the execution queue(s) to which the generic queue can send jobs. You must supply at least one execution queue name for each generic queue definition. In Example 3-4, the generic queue will send print jobs to two execution queues: LN03R_TTB4 and LN03R_TTB7.
P3 (optional)	Default PRINT parameters. In Example 3-4, LAYUP=LPS$SINGLEHOLES provides a default layup definition file for the generic queue.
P4 (optional)	Explicit INITIALIZE/QUEUE qualifiers.
P5 (optional)	Setting of the SET VERIFY command. The default is SET NOVERIFY.