| Previous | Contents | Index |
Use the following format for serial printers:
| If Your Serial Printer is On... | Use This Format ... | Where ... |
|---|---|---|
| A local serial line | "SERIAL/T xyn" | x is the printer type code, y is the controller name, and n is the host system unit number. |
| A LAT port | "SERIAL/LTA n" | n is the host system unit number. |
The SET TERMINAL and SET DEVICE commands translate the name of the printer for serial printers. To prevent the commands from translating the printer name, prefix the printer name with an underscore (_). |
Enter the device information in the following format:
"IP_CPAP/address" |
where address is the IP address of your DIGITAL PrintServer printer in either a named or numeric format.
For example, a PrintServer TCP/IP node could be specified by either of the following:
"IP_CPAP/garmnd.dsg.dec.com" "IP_CPAP/16.128.144.11" |
Enter the device information in the following format:
"DECNET/nodename" |
where nodename is the DECnet node name of your DIGITAL PrintServer printer.
For example, a PrintServer DECnet node could be specified by:
"DECNET/GARMND" |
You can include printers in your printing system that are connected to an AppleTalk network. To make an AppleTalk printer a network sharable device, the PATHWORKS AppleTalk for VMS software component must be running on the same node that is running the DCPS queue.
The configuration of this type of network is described in the PATHWORKS for VMS (Macintosh) Introduction to the AppleTalk Network System manual.
Enter the device information in the following format:
"APPLETALK/printername@zone@type" |
where:
When only printername is required, the information provided for P2 would be just "APPLETALK/printername" .
For example, an AppleTalk printer could be specified by any of the following:
"APPLETALK/Paul's Printer" "APPLETALK/Paul's Printer@MRO" "APPLETALK/Paul's Printer@MRO@LaserWriter" |
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 - Device name DCPS_LIB - ! P3 - Logical name for your library search list "NUMBER_UP=2" ! P4 - Defines a default queue parameter |
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:
DATA_TYPE=AUTOMATIC
INPUT_TRAY=printer-specific1
LAYUP_DEFINITION=no default layup definition
MESSAGES=NOMESSAGES
NUMBER_UP=0
OUTPUT_TRAY=printer-specific1
PAGE_LIMIT=no limit
PAGE_ORIENTATION=PORTRAIT
PAGE_SIZE=(same as SHEET_SIZE)
SHEET_COUNT=1
SHEET_SIZE=printer-specific1
SIDES=printer-specific1
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:
/DEFAULT=(FORM=MYFORM,NOFEED) |
If you include more than one qualifier in the queue definition, enclose the values in quotation marks. |
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.)
1 These settings depend on the setting of the printer's PostScript interpreter. |
3.4 Customizing Execution Queue Behavior
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.4.1 Running DCPS as a Multistreamed Process
A DCPS symbiont is capable of running as a multistreamed process. As a multistreamed symbiont process, 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 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 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 is not defined, a DCPS process will support only one (1) execution queue.
$ DEFINE/SYSTEM/EXECUTIVE DCPS$MAX_STREAMS max-number |
Execute your DCPS$STARTUP.COM file to enable this logical 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.4.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. 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-MAR-2001 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. |
| Previous | Next | Contents | Index |