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. As previously stated, the number of streams (queues) that a DCPS process supports is determined by the value of the logical DCPS$MAX_STREAMS when a new process is started. A symbiont process terminates when all the queues supported by that process are stopped.

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 which identifies the process ID for a queue ( Section 5.8). You can use these logicals 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/ID will stop all of the queues supported by that process.

3.4.1.2 Changing the DCPS Environment when Running Multistreamed

With a single-streamed DCPS symbiont process, changes to DCPS logicals and other aspects of the DCPS environment may not take effect until after you have issued a STOP/RESET and then a START 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.4.2 Interrupting Busy Printers When a Job Starts

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-wide logical to restore the more aggressive behavior:

$ DEFINE/SYSTEM/EXECUTIVE DCPS$queuename_INTERRUPT_WHEN_BUSY 1

3.4.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 HP 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 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 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/SYSTEM/EXECUTIVE DCPS$queuename_NO_SYNC 1

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 loose print jobs if the printer data cable is disconnected or the printer is powered off.

3.4.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:

$ DEFINE/SYSTEM/EXECUTIVE 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.4.5 Suppressing the OPCOM Message "User Name Not Found"

When DCPS is executing in a cluster environment where the UAF files are different between cluster members, an OPCOM message is displayed and the job prints normally:

%%%%%%%%%%% OPCOM 1-MAR-2000 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, the symbiont cannot perform the MESSAGES=KEEP or MESSAGES=PRINT parameter request.

To keep this OPCOM message from being displayed for every job:

$ DEFINE/SYSTEM/EXECUTIVE DCPS$queuename_IGNORE_UNKNOWN_USER 1

3.4.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:

$ DEFINE/SYSTEM/EXECUTIVE DCPS$queuename_OLD_ANSI_PAGE_SIZES 1

3.5 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-3 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-3 Setting Up a Generic Queue

$ @SYS$STARTUP:DCPS$GENERIC_QUEUE - DRAFT_DOCS - ! P1 - Generic queue name "LN03R_TTB4,LN03R_TTB7" - ! P2 - Execution queue names "LAYUP=LPS$SINGLEHOLES" ! P3 - Default queue parameters "" - ! P4 - Default queue qualifiers "" ! P5 - Verify on/off

Table 3-2 Parameter Values for Generic Queues

Parameter	Value
P1 (required)	Name of the generic queue. In Example 3-3, 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-3, the generic queue will send print jobs to two execution queues: LN03R_TTB4 and LN03R_TTB7.
P3 (optional)	Default PRINT parameters. In Example 3-3, 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.

3.6 Activating Changes to the Queue Definitions

When you create or modify the DCPS$STARTUP.COM file, you must activate the changes for the DECprint Supervisor to use the new queue definitions. You can wait until you stop and restart the system, or you can execute the DCPS$STARTUP.COM file, as follows:

1. Stop the print queues that you modified. If any of the modified queues are running on a multistreamed symbiont, stop all other queues that are using that same symbiont (see Section 3.4.1.2). To stop the queues, enter the following command for each print queue:

   $ STOP/QUEUE/NEXT queuename

2. Edit the system startup file SYS$MANAGER:SYSTARTUP_VMS.COM to include a command that invokes DCPS$STARTUP.COM.
   Look for the following command in the system startup file:

   $ @SYS$STARTUP:DCPS$STARTUP

   
   If this command is not in the system startup file, add it to the file. Use the following guidelines:

   • If you are using a printer with TCP/IP, add the new line after TCP/IP is started.
   • If you are using a printer with LAT, add the new line after LAT is started.
   • If you are using a printer with AppleTalk, add the new line after AppleTalk is started.
   • If you are using a PrintServer printer with DECnet, add the new line after the command to invoke STARTNET.COM. PrintServer Software must be running on the PrintServer host system before you start the queues.
   • If the system startup file includes a command to start
     LPS$STARTUP.COM, replace it with the command to start DCPS$STARTUP.COM.
   • If you are upgrading from DECprint Printing Services (CPS), delete the command to start CPS$STARTUP.COM from the system startup file.
3. Execute the printer startup command file:

   $ @SYS$STARTUP:DCPS$STARTUP.COM

If the queues are on a VMScluster system, you should execute the command above from all nodes in the cluster.

The print queues are started by the printer startup command file. See Section 3.7 for information on testing your new queue definitions.

3.7 Testing the Printing System

You can test the printing system by printing the IVP files from SYS$COMMON:[SYSTEST.DCPS]. The IVP files represent the different data types that DCPS supports. The IVP files are listed in Table 3-3.

Table 3-3 IVP Files with Different Data Types

File Name	File Type	Requires DCPS-PLUS?
DCPS$IVP_ANSI.DAT	ASCII files	No
DCPS$IVP_LIST.DAT	Simple ASCII	Yes
DCPS$IVP_PCL.DAT	PCL Level 4 files	Yes 1
DCPS$IVP_POST.DAT	PostScript files	No
DCPS$IVP_PROPRINTER.DAT	Proprinter files	Yes
DCPS$IVP_REGIS.DAT	ReGIS files	Yes
DCPS$IVP_TEK4014.DAT	Tektronix 4010/4014 files	Yes

If you have the DCPS--PLUS license, the software can automatically detect the file's data type. You do not have to specify the data type on the command line. For example, you can enter the following PRINT command:

$ PRINT/QUEUE=queuename/NOTIFY DCPS$IVP_data-type.DAT

If you do not have the DCPS-PLUS license, or the print queue is linked to a specific data type, or you are testing the LIST data type, specify the data type of the file.

For example, to print DCPS$IVP_POST.DAT, use the following PRINT command:

$ PRINT/QUEUE=queuename - /PARAMETERS=DATA_TYPE=POSTSCRIPT/NOTIFY - SYS$COMMON:[SYSTEST.DCPS]DCPS$IVP_POST.DAT

With the DCPS--Plus license, the DECprint Supervisor software can determine the data type of the file to be printed. This chapter explains how you can customize your printing system to print the types of files that users need to print.

4.1 How DCPS--Plus Automatically Detects Data Type

If a user does not specify the data type and the print queue has no default data type, DCPS--Plus examines each file in the print job. DCPS--Plus attempts to determine the data type of the file from instructions in the file, or from the file name extension.

If DECprint Supervisor software cannot determine the file data type by any of these methods, the file is printed as a text file. Text files are handled as ANSI files unless another default text file data type (PCL or Proprinter) has been defined by the system manager for the queue or for the system.

When files are treated as text files in this way, the DECprint Supervisor software can detect PostScript data after the text, so a file that starts with text followed by PostScript is printed properly.

The process of determining the file data type is repeated for each file in a print job, so a single print job can contain different types of files.

4.2 Specifying Automatic Data Type Detection

You can control how the DECprint Supervisor software determines the data type of files as they are printed. You can:

• Link file extensions with data types. You can edit the default file extension data file to add or modify the standard list of file extensions and the data types to which they are associated. See Section 4.2.1.
• Specify the default data type to use when DCPS--Plus cannot determine the file's data type in any other way. You can specify a system wide default and a queue-specific default text data type. See Section 4.2.2.

If necessary, you can create generic queues that have default data types, so that every file sent to the queue is assumed to be that data type. Only the user's PRINT parameters can override the queue default data type.

4.2.1 Linking File Extensions with Data Types

The DECprint Supervisor software uses a data file to link file extensions to data types. Use the following procedure to create a local data file of your system's file extensions and the associated data types.

1. If your system does not have a customized data file, use the sample file supplied with your software. Copy the file, and change the file's extension, as shown in the following command:

   $ COPY _From: SYS$LIBRARY:DCPS$FILE_EXTENSION_DATA_TYPE.DAT_DEFAULT _To: SYS$COMMON:[SYSLIB]DCPS$FILE_EXTENSION_DATA_TYPE.DAT

   
   If the .DAT file is not in variable or stream format, DCPS cannot read it when the queues are started. OPCOM will report the error, and the symbiont process may be terminated. You should save the .DAT file in the appropriate format, and then restart the printing system using the DCPS$STARTUP.COM file.
   

2. Edit the file. The file has the default file extension and data types listed. For example:

   POSTSCRIPT: EPS EPSF POST PS ;

   
   The example shows that files with extensions of .EPS, .EPSF, .POST, and .PS are linked to the PostScript data type.
   Add extensions that are specific to your site, or modify any that have a different local meaning.
   You can specify any valid DATA_TYPE value, except AUTOMATIC. Do not abbreviate the data type names. The valid data type names are:

   • ANSI
   • ASCII
   • DDIF
   • LIST
   • PCL
   • POSTSCRIPT
   • PROPRINTER
   • REGIS
   • TEK4014

You can specify a system wide default text data type and queue-specific default text data types. If DCPS--Plus software cannot determine the data type, the file is processed as the default data type you specify.

The factory default data type is ANSI. If users regularly print PCL or Proprinter text files instead of ANSI files, you should change the default from ANSI to PCL or Proprinter.

Define one or both of the following logical names:

• DCPS$DEFAULT_TRANSLATOR specifies the system wide default text data type.
  To define a system wide default text data type, use the following command:

  $ DEFINE/SYSTEM/EXECUTIVE DCPS$DEFAULT_TRANSLATOR text_data_type

• DCPS$queuename_DEFAULT_TRANSLATOR specifies the queue-specific default data type.
  To define a queue-specific default text data type, use the following command:

  $ DEFINE/SYSTEM/EXECUTIVE DCPS$queuename_DEFAULT_TRANSLATOR text-data-type

Valid values for the text-data-type are:

• ANSI (the default)
• PCL
• PROPRINTER

Do not abbreviate the data type name.

If the system wide data type differs from the queue-specific data type, the queue-specific data type takes precedence.

The queue-specific logical name is useful when a queue is used by PATHWORKS clients. Text files printed from PCs may be PCL or Proprinter files. The following example specifies the PCL data type for the queue named PATHWORKS:

$ DEFINE/SYSTEM/EXECUTIVE DCPS$PATHWORKS_DEFAULT_TRANSLATOR PCL

The DECprint Supervisor software attempts to determine the file data type for each file sent to the PATHWORKS queue. If a file data type cannot be determined, the file is processed as a PCL file. If the file contains PCL text followed by PostScript, it is printed properly.

4.2.3 How Users Control Data Type Detection

Users control the way print jobs are processed for automatic data type detection by specifying:

• The data type with the /PARAMETERS=DATA_TYPE qualifier in the PRINT command.
  This qualifier overrides the automatic data type detection process; only the presence of DDIF file tags can prevent the file from being processed using the translator associated with the specified data type. If the file contains DDIF tags and is explicitly specified as another data type, the file is not printed. The following error message is displayed, and the DECprint Supervisor software continues with the next file in the print job (if any):

  INVDDIFDATA, Invalid DDIF data, flushing to end of file

• Automatic data type detection with the following PRINT parameter:

  /PARAMETERS=DATA_TYPE=AUTOMATIC[=text-data-type]

  
  Users can specify the /PARAMETERS=DATA_TYPE=AUTOMATIC qualifier to specify automatic data type detection (for example, if the print queue has a default data type).
  If the user includes the default text data type (text-data-type) in the DATA_TYPE=AUTOMATIC parameter, the DECprint Supervisor software assumes the specified data type if the data type of a print file cannot be determined.
  The text-data-type value is optional; the default is ANSI. Users should include this value to specify another text data type, such as PCL or Proprinter.
  The DECprint Supervisor software can print a file that starts with the default text data type followed by PostScript data. If a user needs to print a file that begins with PCL text followed by PostScript data, the user can explicitly set the default text data type to be PCL using the following PRINT command:

  $ PRINT/QUEUE=PS20$A10 PIC.MSG/PARAMETERS=(DATA_TYPE=AUTOMATIC=PCL)

  
  This feature is useful for printing files generated by electronic messaging systems. For example, you can print a PostScript file that was sent to you from someone using the messaging system, if the resulting file contains a text message header followed by PostScript data.