| Previous | Contents | Index |
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 |
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- 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 |
To keep this OPCOM message from being displayed for every job:
$ DEFINE/SYSTEM/EXECUTIVE DCPS$queuename_IGNORE_UNKNOWN_USER 1 |
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 |
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 |
| 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. |
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:
$ STOP/QUEUE/NEXT queuename |
$ @SYS$STARTUP:DCPS$STARTUP |
$ @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
Execution of the IVP (@SYS$TEST:DCPS$IVP) does not cause anything to print. |
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.
| 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¹ |
| 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:
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.
$ COPY _From: SYS$LIBRARY:DCPS$FILE_EXTENSION_DATA_TYPE.DAT_DEFAULT _To: SYS$COMMON:[SYSLIB]DCPS$FILE_EXTENSION_DATA_TYPE.DAT |
POSTSCRIPT:
EPS
EPSF
POST
PS
;
|
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:
$ DEFINE/SYSTEM/EXECUTIVE DCPS$DEFAULT_TRANSLATOR text_data_type |
$ DEFINE/SYSTEM/EXECUTIVE DCPS$queuename_DEFAULT_TRANSLATOR text-data-type |
Valid values for the text-data-type are:
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:
INVDDIFDATA, Invalid DDIF data, flushing to end of file |
/PARAMETERS=DATA_TYPE=AUTOMATIC[=text-data-type] |
$ PRINT/QUEUE=PS20$A10 PIC.MSG/PARAMETERS=(DATA_TYPE=AUTOMATIC=PCL) |
| Previous | Next | Contents | Index |