This chapter describes the printing services provided by MultiNet. MultiNet supports printing through the LPD, IPP and telnet (STREAM and NTY) protocols.
An LPD server allows other hosts and networks to access queues on the server system. The queues can be any valid OpenVMS queue, including LAT queues and terminal queues, and do not have to be MultiNet print client queues. A MultiNet system is disabled as an LPD server by default in the distribution kit.
To grant access to other hosts or networks, run the MultiNet Server Configuration Utility (SERVER-CONFIG) with the command:
$ MULTINET CONFIGURE /SERVERS
and enable the LPD server:
SERVER-CONFIG>ENABLE LPD
then select the LPD server:
SERVER-CONFIG>SELECT LPD
To add hosts, type the command:
SERVER-CONFIG>SET ACCEPT-HOSTS
You are first prompted to delete the hosts currently in the configuration, then prompted to add new hosts to the configuration by their IP addresses. To add access to all hosts on a particular network, issue the command:
SERVER-CONFIG>SET ACCEPT-NETS
You are prompted in a similar fashion for networks. For additional information on granting and denying access to MultiNet services, see Chapter 12.
Access control changes take effect immediately when you restart the MultiNet master server process with the RESTART command before exiting. To log errors to OPCOM, type this command before restarting the master server process:
$ REPLY/ENABLE=NET/TEMP
The following example shows how to grant LPD access to two specific hosts and to all hosts on a given network. (Note that HOSTS.EQUIV is not consulted when determining trusted hosts.)
$ MULTINET
CONFIGURE /SERVERS
MultiNet Server Configuration Utility 5.6
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>SHOW LPD /FULL
Service "LPD":
TCP socket (AF_INET,SOCK_STREAM), Port 515
Socket Options = SO_KEEPALIVE
INIT() = TCP_Init
LISTEN() = TCP_Listen
CONNECTED() = TCP_Connected
SERVICE() = Run_Program
Program = "MULTINET:SERVER_LPD.EXE"
Accept Hosts = IP*127.0.0.1
Reject by default all other hosts and nets
Reject Message = "Your host does not have line printer access"
SERVER-CONFIG>SELECT LPD
[The Selected SERVER entry is now LPD]
SERVER-CONFIG>SET ACCEPT-HOSTS
Delete address "IP*127.0.0.1" ? [NO]
You can now add new addresses for LPD. An empty line terminates.
Add Address: 10.41.228.1
Add Address: 10.41.228.65
Add Address: RETURN
SERVER-CONFIG>SET ACCEPT-NETS
You can now add new addresses for LPD. An empty line terminates.
Add Address: 10.16.72.0
Add Address: RETURN
SERVER-CONFIG>RESTART
Configuration modified, do you want to save it first ? [YES] RETURN
[Writing configuration to MULTINET_COMMON_ROOT:[MULTINET]SERVICES.MASTER_SERVER]
%RUN-S-PROC_ID, identification of created process is 202002BD
SERVER-CONFIG>EXIT
[Configuration not modified, so no update needed]
$
A print request expects to be printed under a valid OpenVMS user name. If the print request originates from a remote system, the user name may not map to a valid OpenVMS user name. When defining a default LPD user name, any print request that does not map to a valid OpenVMS user name maps to the default LPD user name, and is accepted by the LPD server.
It is recommended that you define the default LPD user name even if the user names on the remote system match those on the OpenVMS system. Some printing systems use the name root or lpd instead of the actual user name when dispatching a print job to a remote system; those names may not match any valid OpenVMS user name. To set a default LPD user name:
$ MULTINET
CONFIGURE
MultiNet Network Configuration Utility 5.6
[Reading in MAXIMUM configuration from MULTINET:MULTINET.EXE]
[Reading in configuration from MULTINET:NETWORK_DEVICES.CONFIGURATION]
NET-CONFIG>SET LPD-DEFAULT-USERNAME PYEWACKET
NET-CONFIG>EXIT
[Writing configuration to MULTINET:NETWORK_DEVICES.CONFIGURATION]
[Writing Startup file MULTINET:START_MULTINET.COM]
[Changes take effect after the next VMS reboot]
To make the default user name take effect immediately without rebooting the system, define the following logical:
$ DEFINE/SYSTEM/EXECUTIVE MULTINET_LPD_DEFAULT_USERNAME "PYEWACKET"
|
Note: The LPD default user name must exist in the UAF file. It can be non-privileged and it can be "dis-usered," but it must exist.
|
You can set up logical names to map remote LPD users to local users through a mechanism known as proxy access. Using logical names is useful when you want to receive LPD print jobs from a UNIX system on which the user names and UIDs on the client and server are completely uncoordinated.
Proxy mappings take precedence over the default mapping. To map a remote user's LPD requests for printing as if they were queued by a local user:
$ DEFINE/SYSTEM/EXECUTIVE MULTINET_LPD_PROXY_'user' 'local_user'
For example, to map remote user BROWN's LPD requests for printing as if they were queued by the local user JONES:
$ DEFINE/SYSTEM/EXECUTIVE MULTINET_LPD_PROXY_BROWN JONES
By default, LPD print jobs (and SMTP mail messages) on the OpenVMS system are stored in the directory MULTINET_COMMON_ROOT:[MULTINET.SPOOL]. You can change the directory with the NET-CONFIG SET SPOOL-DIRECTORY command:
$ MULTINET
CONFIGURE
NET-CONFIG>SET SPOOL-DIRECTORY DISK$TEMP:[MULTINET]
You must redefine the logical that points to the spooling area unless you reboot the system after modifying the MultiNet configuration. Make sure the directory protections are set to SYSTEM:RWED, OWNER:RWED, GROUP:RE, and WORLD:RE.
$ DEFINE/SYSTEM/EXEC MULTINET_SPOOL DISK$TEMP:[MULTINET]
MultiNet includes an implementation of the UNIX lprm utility which you can invoke with the MULTINET LPRM command. LPRM removes print jobs from remote UNIX (LPD) print queues and can be run by users.
Specify the jobs to be removed by job number. If you do not specify any jobs, the currently active job is deleted by default. The remote LPD queue associated with SYS$PRINT on the local system is used by default in the MULTINET LPRM command.
Use the /QUEUE qualifier to specify an alternate print queue, and the /USER qualifier to specify an alternate user name for the jobs to be deleted.
|
Note: You must have either SYSPRV or OPER privileges to specify a user name other than your own. To cancel all LPD print jobs, use the /SUPERUSER qualifier (which also requires SYSPRV privilege).
|
If the logical MULTINET_LPD_DO_ASYNC_LOOKUP is not defined to 1, True, or Yes, then the LPD print symbiont will now resolve the remote host name with getaddrinfo, and is capable of resolving and connecting to an IPv6 address.
$ DEFINE/SYSTEM/EXEC MULTINET_LPD_DO_ASYNC_LOOKUP TRUE
Once you have set up the LPD server to accept incoming connections, you must set up the remote system for remote printing. When setting up print queues on other systems, specify the OpenVMS queue name as the remote printer name. (You can use the # character in remote printer names.) For example, an Apple LaserWriter is attached to the MultiNet host ABC.COM and is configured as the queue SYS$PRINT. To configure a remote printer queue named "laser" on a UNIX system to direct output to SYS$PRINT on EXAMPLE.COM, add the following entry to /etc/printcap:
laser|lw|LaserWriter II on host EXAMPLE.COM:\
:rm=abc.com:rp=sys$print:sd=/var/spool/laser:lp=:
The following fields are required:
|
Name |
Purpose |
|
laser |
Remote system queue name; in this example, laser |
|
rm |
Node name of the OpenVMS LPD server |
|
rp |
OpenVMS queue name on the OpenVMS LPD server |
|
sd |
Local UNIX spool directory |
|
lp |
Set to null to avoid LPD bugs |
When a user on the UNIX system issues this command:
% lpr -Plaser foo
lpr searches /etc/printcap on the local system for an entry of "laser", and transfers the file "foo" to the LPD server on ABC.COM, which queues "foo" to SYS$PRINT.
To display the contents of a remote queue that serves an OpenVMS print queue, use the command:
$ MULTINET SHOW /QUEUE=vms_queue_name
vms_queue_name is the name of the local OpenVMS queue.
The contents of the remote queue are accessed for display using the TCP LPD service.
|
Note: Queues configured with the STREAM protocol cannot be displayed with this command.
|
MultiNet allows control of the job-queueing parameters used for incoming LPD print jobs using logical names. The formats for these logical names, which specify their scope, are:
MULTINET_LPD_queuename_typechar_parametername
Specifies a parameter value for a specific queue and file type.
MULTINET_LPD_queuename_*_parametername
Specifies the default for a specific queue and all file types on that queue.
MULTINET_LPD_*_typechar_parametername
Specifies the default for all queues with a specified file type.
MULTINET_LPD_*_*_parametername
Specifies a default for all queues and all file types.
Enter an asterisk in a logical name to match any queuename or typechar. An asterisk cannot be used for a parametername. The values in the logicals are:
· parametername, which is one of the following:
|
Value |
Description |
|
P1, P2, P3, P4, P5, P6, P7, P8 |
OpenVMS print job parameters [PRINT /PARAM=()] |
|
BURST |
/BURST qualifier (ALL, ONE, or NO) |
|
FEED |
/FEED qualifier (YES or NO) |
|
FILETYPE |
Type of spool file (FIXED512 or LFSTREAM) |
|
FLAG |
/FLAG qualifier (ALL, ONE, or NO) |
|
FORM |
Form name |
|
PASSALL |
/PASSALL qualifier (YES or NO) |
|
SETUP |
/SETUP qualifier, list of setup modules |
|
TRAILER |
/TRAILER qualifier (ALL, ONE, or NO) |
· queuename, the name of a printer visible to LPD clients.
· typechar, a single letter specifying the file's data type; accepted values are c, d, f, g, l, n, p, r, t, and v. The f value is the lpr default if a user does not specify a type flag. r is required if a user specifies -f.
For example, if you want print jobs sent to your system via LPD and submitted to an OpenVMS print queue called PRINT01 to use the bottom input tray, you would issue this command:
$ DEFINE/EXEC/TABLE=MULTINET_PRINTER_TABLE
-
_$ MULTINET_LPD_PRINT01_*_P1
"INPUT_TRAY=BOTTOM"
These logical names must all be defined in the MULTINET_PRINTER_TABLE logical name table. If you have not already run PRINTER-CONFIG, the MULTINET_PRINTER_TABLE logical name table may not exist. Verify the MULTINET_PRINTER_TABLE logical name table exists:
1. Start PRINTER-CONFIG with the following command:
$ MULTINET CONFIGURE /PRINTERS
2. Save the unmodified configuration:
PRINTER-CONFIG>SAVE
This command writes the file MULTINET:REMOTE-PRINTER-QUEUES.COM which contains the command to create the MULTINET_PRINTER_TABLE logical name table.
3. Exit PRINTER-CONFIG.
PRINTER-CONFIG>EXIT
4. Execute the MULTINET:REMOTE-PRINTER-QUEUES.COM command procedure.
|
Note: MULTINET:REMOTE-PRINTER-QUEUES.COM is executed automatically when MultiNet starts. If you define these logical names manually, they will be lost after rebooting. To preserve your logical name definitions, add the appropriate DEFINE commands to your startup command procedure.
|
The following example shows how to configure the MultiNet LPD server to handle inbound jobs submitted with the -v option.
$ DEFINE/EXECUTIVE_MODE/TABLE=MULTINET_PRINTER_TABLE
-
_$ MULTINET_LPD_*_V_PASSALL "YES"
$ DEFINE/EXECUTIVE_MODE/TABLE=MULTINET_PRINTER_TABLE
-
_$ MULTINET_LPD_*_V_FILETYPE "FIXED512"
The following example specifies that all LPD jobs queued to SYS$PRINT be submitted with the form "WIDE":
$ DEFINE/EXECUTIVE_MODE/TABLE=MULTINET_PRINTER_TABLE
-
_$ MULTINET_LPD_SYS$PRINT_*_FORM WIDE
The MULTINET_PRINTER_TABLE logical name table and all logical names within the table must be defined in executive mode. To confirm this, enter the following command:
$ SHOW LOGICAL/FULL/TABLE=MULTINET_PRINTER_TABLE
MULTINET_PRINTER_queuename_PASSALL_FILTER if a queue or a
job is set to
/PASSALL, this logical makes the default filter
character "v" unless this logical exists
and specifies a different value.
MULTINET_PRINTER_queuename_SUPPRESS_REMOTE_BANNER if defined, does not include the "L" command in the control file to request a banner page.
MULTINET_PRINTER_queuename_NO_FFLF_DEFAULT or MULTINET_PRINTER_*_NO_FFLF_DEFAULT if the value is "Y", "T" or "1", then NOFFLF is enabled; otherwise it is disabled.
The error message "record too large for user's buffer," indicates a file format problem. Define the following logicals, and specify that all print commands and any print qualifiers are treated as fixed 512-byte files.
$ DEFINE/EXECUTIVE_MODE/TABLE=MULTINET_PRINTER_TABLE –
_$ MULTINET_LPD_*_*_PASSALL TRUE
$ DEFINE/EXECUTIVE_MODE/TABLE=MULTINET_PRINTER_TABLE -
_$ MULTINET_LPD_*_*_FILETYPE FIXED512
For information about interpreting the asterisk (*) in logical names, see the LPD Jobs (Inbound) section.
The file is removed from the queue on the client side, but the job never appears in the OpenVMS queue. Enable OPCOM with the command:
$ REPLY/ENABLE=NET/TEMP
and try the PRINT command again. The OPCOM error message, "your host does not have line printer access," indicates that the server has not been set up to allow incoming connections from the remote host. See the Configuring the LPD/LPR Server section.
If no OPCOM error messages display, use the following command to verify that the default LPD user name has been defined in EXECUTIVE mode:
$ SHOW LOGICAL/FULL MULTINET_LPD_DEFAULT_USERNAME
If the logical does not exist, or is not defined in executive mode, refer to the Setting a Default LPD User Name section.
To generate a log file with LPD, do the following:
$ DEFINE/SYSTEM MULTINET_LPD_SYMBIONT_DEBUG
A value is not required for the logical. If the logical exists, debug logging is ON; if the logical does not exist, debug logging is OFF. The equivalence string for the logical is not checked.
Restart the queue. If the OPCOM messages are enabled, a notification is printed telling you that debugging is enabled.
To turn off the SYMBIONT log file, deassign the logical and restart the SYMBIONT queue(s) that were (re)started since you defined the logical because the symbiont only looks for the logical when the queue starts up.
$ DEASSIGN/SYSTEM MULTINET_LPD_SYMBIONT_DEBUG
The log files are created in MULTINET_SPOOL:LPD_DEBUG_pid.LOG
pid is the hexidecimal process ID of the symbiont process in question. There may be as many as 16 queues sharing the same log file, since log files are per symbiont process, not per queue, and each process can support processing for up to 16 queues.
The error message Invalid data file size received, indicates a LPR client sent an invalid printing job. This could occur if a Windows 2000 LPR client is wrongly configured.
This section describes how to configure a TCP/IP print queue using MultiNet. MultiNet supports two printer protocols: STREAM and LPD. Set up print queues using the interactive MultiNet PRINTER-CONFIG utility, which is used to configure OpenVMS TCP/IP printer queues.
PRINTER-CONFIG creates and maintains configuration information about MultiNet TCP/IP queues. By default, this utility stores configuration information in the file MULTINET:REMOTE-PRINTER-QUEUES.COM, which also contains the necessary DCL commands to configure the printer pseudo-devices and set up the OpenVMS print queues.
After using this utility to configure the queue, invoke the command procedure MULTINET:REMOTE-PRINTER-QUEUES.COM to create an OpenVMS queue on the system. You can invoke this command procedure at any time to initialize a new queue without affecting any queues already running. Use this queue exactly like any other OpenVMS queue; it responds to standard OpenVMS PRINT and QUEUE commands. To run the printer queue configuration manager, issue the command:
$ MULTINET CONFIGURE/PRINTERS
The LPD protocol is a standard for sharing printers between hosts on an IP network. The protocol is defined by RFC-1179, and is integrated into the OpenVMS printing system with the MULTINET_LPD_SYMBIONT executable. LPD was originally intended for system-to-system print job transfers, but many printer Ethernet cards now support LPD protocol so that LPD can be used for printing directly to a printer. The following parameters are used with the MULTINET_LPD_SYMBIONT:
· ADDRESS=host_addr or ADDRESS:host_addr
· CLASS=class_string or CLASS:class_string
· FILTER=filter_char or FILTER:filter_char
· NOFFLF=Y/T/1 or NOFFLF:Y/T/1
· PRINTER=remote_queue_name or PRINTER:remote_queue_name
· RETAIN_CR=Y/T/1 or RETAIN_CR:Y/T/1
This protocol separates the print job into two parts:
· A df file (data file) that contains the actual data in the print file
· A cf file (control file) that contains commands for how the file should be printed
The df file is sent first and must be spooled on the server until the cf file arrives with instructions for how the server should print the file. This process causes more overhead when printing a file.
If you are using the LPD protocol to print directly to a printer, make sure the printer's network interface supports LPD. Consult the printer interface documentation to confirm this. To initially configure an LPD queue, use the PRINTER-CONFIG ADD command. The utility prompts you for the following information:
Remote Host Name:
The IP address of the remote system or printer to which the print job will be sent. The address may be specified in standard "dot" notation (i.e. 123.456.789.012), or as a DNS name if there is an entry in the DNS server or host table of the sending system for the printer or terminal server in question.
Protocol Type: [LPD]
Press RETURN to accept the default (LPD protocol).
Remote Queue Name: [lp]
A remote queue name used by the LPD protocol. If this is a system-to-system print setup, the remote queue name must match the name of an existing queue defined on the remote system. If the print jobs will go directly to a printer, the remote queue name often designates the "spooling" area that exists on the printer's network interface card.
The remote printer queue name is not arbitrary; it is specific to the type of network interface installed in the printer. Consult the printer's network interface documentation for the correct remote queue name.
The following example shows the initial configuration of a queue called HP5 that points to an HP4si printer with an internal HP Jet Direct Card, using LPD protocol.
$ MULTINET
CONFIGURE/PRINTER
MultiNet Remote Printer Configuration Utility 5.6
[Reading in configuration from MULTINET:REMOTE-PRINTER-QUEUES.COM]
PRINTER-CONFIG>ADD HP5
[Adding new configuration entry for queue "HP5"]
Remote Host Name: 10.49.2.3
Protocol Type: [LPD] Return
Remote Queue Name: [lp] TEXT
[HP5 => 10.49.2.3, TEXT]
PRINTER-CONFIG>SHOW HP5
Queue Name IP Destination Remote Queue Name
---------- --------------- -----------------
HP5 10.49.2.3 TEXT
PRINTER-CONFIG>EXIT
[Writing configuration to MULTINET:REMOTE-PRINTER-QUEUES.COM]
Invoke the MULTINET:REMOTE-PRINTER-QUEUES.COM command procedure to initialize the printer queue.
By default, the MULTINET_LPD_SYMBIONT does no input record modification. Records are read in, formatted and presented to the output code by the standard OpenVMS printer symbiont library routines. The LPD protocol is implemented in the output routine of the symbiont. There are times, however, when it may be desirable to handle record input differently. For instance, the standard routines treat records with leading form feed (FF) characters differently from other records. Leading and trailing carriage control is stripped from such records, and, if the record consisted only of a FF character, the leading carriage control bytes of the following record are suppressed. In most cases this yields the desired output on paper, but when it doesn’t, it may be useful to be able to specify other behavior. That’s what the LPD symbiont’s EMBED_CC and ADD_EOR capabilities are intended to help with.
|
Note: Please see the OpenVMS Utility Reference Manual for more information about print symbionts, input filtering and the handling of various file formats.
|
The EMBED_CC and ADD_EOR capabilities are optional, and must be enabled though the use of a new logical name (MULTINET_LPD_SYMBIONT_FILTER_ENABLED) to be usable. Without this logical being present in the system logical name table at the time the symbiont process is started, neither of these capabilities will work This logical causes the symbiont process to initialize differently than it does when the logical is not present. All other symbiont capabilities work normally regardless of the presence or absence of this logical.
The EMBED_CC capability allows the carriage control specified for the file to be embedded in the data records prior to their being passed to the main formatting routine of the OpenVMS print symbiont. The records will have no separate carriage control specified once this is done, and will be equivalent to printing an embedded carriage control file. The carriage control specified for each record can be the default provided by the input routines, or it can be specified on a system, queue, or job basis. If the carriage control is specified, this will override whatever implicit carriage control is present in the file being printed.
The ADD_EOR capability allows specification of a byte to be added to the end of each data record. This byte will follow any leading carriage control bytes, the data, and any trailing carriage control bytes if these are embedded, or precede them if they are not.
The EMBED_CC and ADD_EOR capabilities can be used individually or together, or not used at all, as needs dictate. Both require that the MULTINET_LPD_SYMBIONT_FILTER_ENABLED logical be defined when the symbiont process is first started.
Logical names are used to control these two capabilities on a system-wide or queue-specific basis. PRINT command parameters are used to control them on a per-job basis. See the appropriate sections below for more information on using these capabilities.
MULTINET_LPD_SYMBIONT_FILTER_ENABLED
Define as 1/T/Y to enable EMBED_CC and ADD_EOR capabilities.
Example:
$ DEFINE/SYSTEM/EXECUTIVE_MODE MULTINET_LPD_SYMBIONT_FILTER_ENABLED Y
MULTINET_LPD_EMBED_CC
MULTINET_LPD_queue_EMBED_CC
Turns on carriage control (CC) embedding. Value is the specification for the CC longword if it's an 8-digit HEX number, beginning with 0x. If the value is 1/T/Y it enables embedding of the default CC as handed to the Input_File routine. If the value is 0/F/N, embedding is disabled.
The 8-digit HEX number used to specify an override CC value consists of four bytes, each of which specifies a different aspect of the CC. From lowest order byte (right most) to highest:
Byte 1: Repeat count for Leading CC
Byte 2: Leading CC value
Byte 3: Repeat count for Trailing CC
Byte 4: Trailing CC value
The CC values are the actual ASCII character code value, except that zero is not "NUL", but is used to specify the sequence "CRLF".
Example:
$ DEFINE/SYSTEM/EXECUTIVE_MODE MULTINET_LPD_EMBED_CC "0x0D010A01"
In the preceding example, the four bytes are shown from the highest order byte (fourth) to the lowest order byte (first), with “0D” representing the fourth byte, “01” representing the third byte, “0A” representing the second byte, and “01” representing the first byte. This value would specify a single leading Line Feed (LF) byte, and a single trailing Carriage Return (CR) byte.
$ DEFINE/SYSTEM/EXECUTIVE_MODE MULTINET_LPD_FOOBAR_EMBED_CC "Y"
says to embed the default CC for each record, as specified in the OpenVMS Utility Routines manual. For a Carriage-Return Carriage Control file this is a leading LF, trailing CR, with special handling around FF characters.
|
Note: MULTINET_LPD_SYMBIONT_FILTER_ENABLED must be defined when the symbiont process is started in order for this to be effective!
|
MULTINET_LPD_ADD_EOR
MULTINET_LPD_queue_ADD_EOR
Specifies that an EOR marker byte is to be added to the end of each input record, and what the value of that marker is to be. The marker is specified as either a two-digit HEX number, prefixed with "0x", or the actual ASCII character to use.
Example:
$ DEFINE/SYSTEM/EXECUTIVE_MODE
MULTINET_LPD_ADD_EOR "0x7C"
$ DEFINE/SYSTEM/EXECUTIVE_MODE MULTINET_LPD_ADD_EOR
"|"
These two specifications are equivalent, and will result in a vertical bar, or “pipe”, character being added to the end of each record. If CC is being embedded, this byte will appear following the trailing CC byte(s). If CC is not being embedded, this byte will precede any trailing CC byte(s).
|
Note: MULTINET_LPD_SYMBIONT_FILTER_ENABLED must be defined when the symbiont process is started in order for this to be effective!
|
/PARAMETER=(EMBED_CC=value)
The job parameter equivalent of MULTINET_LPD_EMBED_CC. Value has the same range of options as for that logical.
/PARAMETER=(ADD_EOR=value)
The job parameter equivalent of MULTINET_LPD_ADD_EOR. Value has the same range of options as for that logical.
|
Note: MULTINET_LPD_SYMBIONT_FILTER_ENABLED must be defined when the symbiont process is started in order for either of these to be effective!
|
Three logical names allow you to control LPD queue print job handling. By default, the LPD symbiont passes the letter "f" (for "formatted" file) as the print filter character the LPD server uses when you issue a standard PRINT request to an LPD queue. If you include the /PASSALL qualifier on your print request, the LPD symbiont uses the letter "v" (for "Versatec", that is, binary output) instead. In addition, the LPD symbiont normally strips CR (carriage return) characters from CRLF (carriage return, line feed) line-termination sequences, in keeping with the UNIX notion of LF (Line Feed) as the new-line character.
MULTINET_PRINTER_queuename_DEFAULT_FILTER
Allows you to specify the print filter character to use instead of "f" on the specified LPD queue. Declare the alternative, normal print filter character as follows:
$ DEFINE
/TABLE=MULTINET_PRINTER_TABLE -
_$ MULTINET_PRINTER_queuename_DEFAULT_FILTER "character"
queuename is the name of the queue for which you are modifying the print filter character, and “character" is the character to be used.
You may override both the default character and the
alternative character by including the
/PARAMETER=(FILTER="character") qualifier on your print request (assuming the
logical name MULTINET_PRINTER_queuename_ALLOW_USER_SPEC is defined appropriately).
MULTINET_PRINTER_queuename_ALLOW_USER_SPEC
If defined with an equivalence string of "Y", "T" or "1", the user can specify the ADDRESS and PRINTER values for the print job on the PRINT command, in the /PARAMETERS qualifier. In addition, specifying this logical will result in requeue retries, rather than the default timed retries when there is a problem with a connection. If this logical is not defined, or is defined with some other equivalence string, the ADDRESS and PRINTER parameters entered on the PRINT command by the user will be ignored, and timed retries will be performed.
MULTINET_PRINTER_queuename_PASSALL_FILTER
Allows you to specify the print filter character to use instead of "v" on the specified LPD queue. Declare the alternative passall print filter character as follows:
$ DEFINE
/TABLE=MULTINET_PRINTER_TABLE -
_$ MULTINET_PRINTER_queuename_PASSALL_FILTER "character"
queuename is the name of the queue for which you are modifying the passall print filter character, and "character" is the character to be used.
You may override both the default character and the alternative passall character by including both the /PARAMETER=(FILTER="character") qualifier and the /PASSALL qualifier on your print request.
MULTINET_PRINTER_queuename_RETAIN_CR_DEFAULT
Allows you to specify the disposition of CR characters in CRLF sequences on the specified LPD queue. Change CR processing on the queue as follows:
$ DEFINE /TABLE=MULTINET_PRINTER_TABLE
-
_$ MULTINET_PRINTER_queuename_RETAIN_CR_DEFAULT "boolean"
queuename is the name of the queue for which you are modifying the CR disposition.
"boolean" indicates whether or not CR characters are to be retained in CRLF sequences included in text sent to the remote system for printing.
You may override both the default CR disposition and the alternative disposition by including the /PARAMETER=(RETAIN_CR="boolean") qualifier on your print request.
· The MULTINET_LPD_SYMBIONT_DEBUG logical name enables debug logging.
· The MULTINET_PRINTER_queuename_SUPPRESS_FF logical name controls whether CRFF is added to jobs.
· The MULTINET_PRINTER_queuename_NO_TELNET logical name controls Telnet IAC code expansion.
If you want an extra blank line on each page and, consequently, an extra blank page when the bottom margin has been reached, set the logical MULTINET_NLPx_REMOTE_PRINTER to include the configuration parameter DOLFFF=Y. Depending on your printer, it may be desirable to keep the behavior and not have the extra blank line and extra blank page.
When the symbiont cannot connect to the remote system, or the remote LPD server reports insufficient resources for printing a job, the symbiont requeues the job for a later attempt. Requeue attempts are reported directly to the user who submitted the print job only if the user specified /NOTIFY in the print command. The requeue time is controlled through logical names; you can control the length of time a job will wait before being attempted again after a connection failure by defining a logical name as follows:
$ DEFINE/SYSTEM MULTINET_LPD_SYMBIONT_RETRY_INTERVAL "delta-time"
The default value is "0 00:10:00.00", or ten minutes.
You can also control the maximum amount of time that should elapse before the symbiont gives up on a job with this command:
$ DEFINE/SYSTEM MULTINET_LPD_SYMBIONT_MAX_RETRY_INTERVAL "delta-time"
The default value is "0 02:00:00.00", or two hours.
You must specify the delta-time values in quotation marks, and with a space separating the number of days from the number of hours, so the symbiont can process them correctly.
LPD uses timer retries to queues that are not set up to allow user-specified printer destinations. For the other queues, jobs are placed in the queue to be tried again. The advantage to the timer retries is that successive jobs are not sent to the printer until the symbiont can actually contact the printer. Use the following logical to control timer retry intervals:
$ DEFINE/SYSTEM/EXEC MULTINET_LPD_SYMBIONT_CONNECT_TIMERS “n n”
Its equivalence string should be two numbers, separated by one space, that specify a) the retry interval and b) the maximum retry time, in seconds. By default, the interval starts at 600 seconds (10 minutes); for each retry, that value is doubled until the maximum retry time of 7200 seconds (2 hours) is reached. The default would be represented by the following logical definition:
$ DEFINE/SYSTEM/EXEC MULTINET_LPD_SYMBIONT_CONNECT_TIMERS “600 7200”
· OPCOM messages from the LPD symbiont now include the queue name and entry number associated with the message.
· OPCOM messages from the LPD symbiont can be disabled by defining the following logical:
$ DEFINE/SYSTEM/EXEC MULTINET_PRINTER_NO_OPCOM true
It is recommended that the OPCOM messages not be disabled. They may block legitimate problem messages, in addition to informational messages about trying connections. This logical can be used for both the LPD and STREAM symbionts.
MULTINET_LPD_SYMBIONT_LFTAIL and MULTINET_LPD_SYMBIONT_*_LFTAIL allow reversion to legacy behavior of terminating jobs with an <LF> rather than <CR>. To enable this behavior, use one of these values: Y, T, or 1.
MULTINET_LPD_MAXSTREAMS specifies the maximum number of streams each symbiont process will handle.
MULTINET_LPD_KEEPALIVE turns on keepalives when making socket connections. To enable this behavior, use one of these values: 1, y, Y, t, or T.
MULTINET_LPD_SYMBIONT_RESOURCE_TIMERS specifies the initial and maximum resource retry delay times.
You can define queue parameters on each MultiNet queue using the MULTINET CONFIGURE/PRINTER utility. Refer to the MultiNet Administrator's Reference for specific parameters. The following example shows how to add a device control library called HP3SI to the queue called HP5.
$ MULTINET
CONFIGURE/PRINTER
MultiNet Remote Printer Configuration Utility 5.6
[Reading in configuration from MULTINET:REMOTE-PRINTER-QUEUES.COM]
PRINTER-CONFIG>SELECT HP5
[The Selected Printer is now HP5]
PRINTER-CONFIG>SET LIBRARY HP3SI
[Library HP3SI]
PRINTER-CONFIG>SHOW HP5
Queue Name IP Destination Remote Queue Name
---------- --------------- -----------------
HP5 10.49.2.3 TCP port 9100
Device Control Library = HP3SI
PRINTER-CONFIG>EXIT
[Writing configuration to MULTINET:REMOTE-PRINTER-QUEUES.COM]
Remember to invoke the REMOTE-PRINTER-QUEUES.COM procedure after exiting the configuration utility to add the parameters to the queue. Some parameters are only valid with the INITIALIZE /QUEUE command, so you may need to first stop and delete the queue, then invoke the REMOTE-PRINTER-QUEUE command procedure before the new parameters take effect.
You can start either a single print queue or a list of queues, in addition to starting all print queues using the command procedure MULTINET:REMOTE-PRINTER-QUEUES.COM. The syntax for the command procedure is:
$ @MULTINET:REMOTE-PRINTER-QUEUES [queue1,[queue2,queue3,...]]
If you do not provide any queue names on the command line, the procedure attempts to start all defined queues. For example, to start SYS$PRINT:
$ @MULTINET:REMOTE-PRINTER-QUEUES SYS$PRINT
Or, to start SYS$PRINT and SYS$LASER:
$ @MULTINET:REMOTE-PRINTER-QUEUES SYS$PRINT,SYS$LASER
MultiNet allows users to override some of the parameters that you specify when you configure a print queue. You can enable user-specified print destinations, using the ADDRESS and PRINTER parameters, on a per-queue basis:
$ DEFINE/TABLE=MULTINET_PRINTER_TABLE
-
_$ MULTINET_PRINTER_queuename_ALLOW_USER_SPEC TRUE
If you want to allow users to specify their own print destinations for LPD printing, define this logical name during your system startup sequence. To define the logical using MULTINET CONFIG:
$ MULTINET
CONFIGURE /PRINTER
PRINTER-CONFIG>SELECT queuename
PRINTER-CONFIG>SET ALLOW-USER-SPECIFIC ENABLE
PRINTER-CONFIG>EXIT
To override the parameters associated with an LPD queue, use the /PARAMETERS qualifier with the PRINT command. Specify an alternative destination, a print filter, or how carriage return characters are to be treated with these parameters:
ADDRESS=n.n.n.n
Specifies the address of the destination host. This value must be a numeric IP address, not a host name. If not specified, the address configured for the queue in the MultiNet printer configuration utility (PRINTER-CONFIG) is used.
CLASS=class_string
Specifies the string to put on the "class" line in the control file. This gets used in various ways, but mostly appears on the banner page if one is printed.
“PRINTER=name”
Specifies the name of the printer on the destination host. Use quotation marks around the entire parameter specification, since many systems are case-sensitive regarding printer names. If you specify ADDRESS and omit this parameter, the printer name defaults to "lp." If you omit both ADDRESS and PRINTER, the printer name configured for the queue in the MultiNet printer configuration utility is used.
RETAIN_CR={Y | N}
Specifies whether the symbiont should not convert CR/LF sequences into bare LFs when sending a text file to the remote system. The default is N; CR/LF sequences are converted to bare LFs. A setting of Y means the sequences are not converted. This parameter is ignored if you submit the job with the /PASSALL qualifier.
“FILTER=x”
Specifies the "print filter" character to be sent with the print job to the remote system. Use quotation marks around the entire parameter, since filter specifications are generally case-sensitive. By default, the symbiont uses "f" for text files and "v" for files submitted with the /PASSALL qualifier.
RESTART
Restarts the queues with the modified configuration information.
NOFFLF=Y/T/1
Specifies whether the symbiont does not add a Line Feed after a Form Feed when sending a text file to the remote system.
For example, to print to an alternate destination:
$ PRINT/PARAM=(ADDRESS=192.168.34.22,"PRINTER=HP5",RETAIN=Y,FILTER="1")-
_$ LOGIN.COM
If the case of the printer name or filter character must be preserved, these parameter values must be enclosed in quotes. In the preceding example, the filter character has been specified as a lowercase “l”.
In the example, the LPD client symbiont is instructed to send the file to the LPD server on host 192.168.34.22 for queue HP5, retaining carriage return characters, and using a filter of "l". The queue entry in the local OpenVMS LPD client queue looks like:
$ SHOW
QUEUE/FULL SYS$PRINT
Printer queue SYS$PRINT, stopped, on NODE:NLP8, mounted form DEFAULT
/BASE_PRIORITY=4, /DEFAULT=(FORM=DEFAULT) /OWNER=[SYSTEM]
/PROCESSOR=MULTINET_LPD_SYMBIONT /PROTECTION=(S:M,O:D,G:R,W:S)
Entry Jobname Username Blocks Status
----- ------- -------- ------ ------
795 LOGIN USER 9 Printing
Submitted 23-MAY-2003 09:40 /FORM=DEFAULT
/PARAM=("ADDRESS=192.168.34.22", "PRINTER=HP5",
"RETAIN=Y", "FILTER=1")
/PRIORITY=100
File: _DKA100:[USER]LOGIN.COM;1
You can add special characteristics to queues by using customized command procedures. You can do this globally to all STREAM or LPD queues, or limit them to each individual queue. These command procedures are automatically invoked every time REMOTE-PRINTER-QUEUES.COM is invoked.
A customized command procedure must contain all commands to spool the NLP device to the queue and to initialize the queue. Review the command procedure MULTINET:REMOTE-PRINTER-QUEUES.COM to see how and when these customized command procedures are called.
· To add a special queue characteristic or qualifier to all STREAM queues, create a command procedure called INITIALIZE_STREAM_QUEUE.COM in the MULTINET directory.
· To customize all LPD queues, create a file called INITIALIZE_LPD_QUEUE.COM in the MULTINET directory.
· To customize individual queues, create a file called INITIALIZE_queuename.COM in the MULTINET directory.
The following example shows a customized command procedure to add the /SEPARATE qualifier to a queue called HP5. The file is located in the MULTINET directory and is called INITIALIZE_HP5.COM.
$! Custom initialization
procedure for stream queue HP5
$!
$ NLP_Device = P1
$ Remote_Address = P2
$ Remote_port = P3
$ Default_Form = P4
$!
$ If F$GetDVI(NLP_Device,"SPL") Then Set Device/NoSpool 'NLP_Device'
$ Set Device/Spool=HP5 'NLP_Device':
$ Initialize/Queue/Processor=MultiNet_Stream_Symbiont HP5 -
/On='NLP_Device'/Start/library=hp3sidevctl/separate=(reset=(reset))
$ Exit
|
Note: The customized command procedure must contain all the commands to spool the NLP.
|
The NLP device must be unique for each queue. The MULTINET:REMOTE_PRINTER_QUEUES.COM command procedure chooses the next available NLP device when initializing the queue. To determine the correct NLP device, use PRINTER-CONFIG to add a new queue. After exiting the utility, examine the MULTINET:REMOTE_PRINTER_QUEUES.COM command procedure to determine which NLP device was assigned to the new queue. Use the commands in that command procedure as a template for creating the customized command procedure.
|
Note: REMOTE_PRINTER_QUEUES.COM passes the NLP device name as one of several parameters to the customized command procedure.
|
The print client STREAM protocol is a TELNET-based protocol that is not defined by an RFC. This is the recommended protocol for printing from VAX systems and is integrated into the OpenVMS printing system with the MULTINET_STREAM_SYMBIONT executable.
To initially configure a STREAM queue, use the PRINTER-CONFIG ADD command. The ADD command has a maximum limit of 5000 symbionts per system. The utility prompts you for the following information:
Remote Host Name:
The IP address of the printer or of the terminal server to which the printer is attached. The address may be specified in standard "dot" notation (i.e., 123.456.789.012), or as a DNS name if there is an entry in the DNS server or host table of the sending system for the printer or terminal server in question.
Protocol Type: [LPD]
Type the word STREAM to indicate STREAM protocol.
TCP Port Number: [23]
The port number to which the TCP/IP connection will attach. If the printer has an Ethernet card installed in it, the port number is listed in the Ethernet card documentation; check there first, or call the card manufacturer to confirm the port number. For example, HPLJ Jet Direct cards use port 9100 for the TCP port number.
If the printer is attached to a terminal server, the port number refers to the physical port on the terminal server to which the printer is attached. For example, the HP 90TL terminal server adds 2000 to the actual physical port number to address the correct port. If the printer is physically attached to port 3, add 2000 to 3, making the port number 2003. Direct any questions on addressing the correct port number to the appropriate terminal server vendor.
The following example shows the initial configuration of a queue called HP5 that points to an HP4si printer with an internal HP Jet Direct Card, using STREAM protocol. (For terminal servers, such as the HP 90TL, make sure the logical name MULTINET_PRINTER_printername_NO_TELNET is enabled. where printername is the name that was given to the printer in MU CONFIGURE /PRINTERS.)
$ MULTINET
CONFIGURE/PRINTER
MultiNet Remote Printer Configuration Utility 5.6
[Reading in configuration from MULTINET:REMOTE-PRINTER-QUEUES.COM]
PRINTER-CONFIG>ADD HP5
[Adding new configuration entry for queue "HP5"]
Remote Host Name: 192.168.2.3 or printer.example.com
Protocol Type: [LPD] STREAM
TCP Port Number: [23] 9100
[HP5 => 192.168.2.3, TCP port 9100 (no telnet option negotiation)]
PRINTER-CONFIG>SHOW HP5
Queue Name IP Destination Remote Queue Name
---------- -------------- -----------------
HP5 192.168.2.3 TCP port 9100
Telnet Options Processing will be suppressed
PRINTER-CONFIG>EXIT
[Writing configuration to MULTINET:REMOTE-PRINTER-QUEUES.COM]
Invoke the MULTINET:REMOTE-PRINTER-QUEUES.COM command procedure to initialize the printer queue.
To generate a log file with STREAM, do the following:
$ DEFINE/SYSTEM MULTINET_STREAM_SYMBIONT_DEBUG
A value is not required here as with NTYSMB. If the logical exists, debug logging is ON; if the logical does not exist, debug logging is OFF. The equivalence string for the logical is not checked.
Restart the queue. If the OPCOM messages are enabled, a notification is printed telling you that debugging is enabled.
To turn off the STREAM log file, deassign the logical and restart the STREAM queue(s) that were (re)started since you defined the logical because the symbiont only looks for the logical when the queue starts up.
$ DEASSIGN/SYSTEM MULTINET_STREAM_SYMBIONT_DEBUG
The log files are created in MULTINET_SPOOL:STREAM_DEBUG_pid.LOG
pid is the hexidecimal process ID of the symbiont process in question. There may be as many as 16 queues sharing the same log file, since log files are per symbiont process, not per queue, and each process can support processing for up to 16 queues.
· The MULTINET_STREAM_SYMBIONT_DEBUG logical name enables debug logging.
· The MULTINET_PRINTER_queuename_SUPPRESS_FF logical name controls whether CRFF is added to jobs.
· The MULTINET_PRINTER_queuename_NO_TELNET logical name controls Telnet IAC code expansion.
· If MULTINET_STREAM_DO_ASYNC_LOOKUP is not defined to 1, True, or Yes, then the stream print symbiont will now resolve the remote host name with getaddrinfo, and is capable of resolving and connecting to an IPv6 address.
· The MULTINET_STREAM_DEAD_LINK_TIMEOUT and MULTINET_STREAM_queuename_DEAD_LINK_TIMEOUT logical name control dead link detection and handling.
The MULTINET_STREAM_SYMBIONT can be configured for detection and handling of "dead links", that is, a TCP/IP link that stops responding, but was not closed properly by the remote end.
To enable dead link detection, define a system logical:
$ DEFINE/SYSTEM MULTINET_STREAM_DEAD_LINK_TIMEOUT "timeout_secs [[requeue_secs] option]"
or:
$ DEFINE/SYSTEM MULTINET_STREAM_queuename_DEAD_LINK_TIMEOUT "timeout_secs [[requeue_secs] option]"
Both of the _secs values are integers specifying seconds. Timeout_secs is the number of seconds a write has to take before it is considered a dead link. Requeue_secs specifies how many seconds to hold a job if it gets requeued due to a dead link. Option is one of the following:
· "REQUEUE" - requeue the job with a hold for requeue_secs.
· "CONTINUE" - continue with job...just open a new link.
· "STOP" - stop the queue.
The default behavior is "REQUEUE" if none is specified explicitly, and the default requeue_secs is zero (that is, no delay) if no time is specified.
|
Note: None of these guarantee that a print job will not be affected adversely by a lost link, especially when it is due to the printer interface being powered off suddenly.
|
A problem can occur when the symbiont tries to open a connection and the remote host refuses the connection. Possible reasons for this refusal could be that there is another connection already open on that port by another system or the connection from the previous job the symbiont sent has not finished closing. You can control how long the symbiont waits to retry a connection after it is refused with the MULTINET_STREAM_SYMBIONT_TIMERS logical. The logical sets the initial and the maximum time to wait before retrying the connection. For example, if you defined the logical as follows it would retry the connection after 1 second and double the time between subsequent retries until it reached the maximum of 10 seconds.
$ DEFINE/SYSTEM/EXEC MULTINET_STREAM_SYMBIONT_TIMERS "1 10"
A user exit is a mechanism for customizing the way the print symbiont sends jobs to the printer, beyond the methods provided by MultiNet. A user exit is a shareable image that contains symbols the symbiont reads at runtime for special processing instructions.
The file MULTINET_ROOT:[MULTINET.EXAMPLES]USER_LPD_CLIENT.C (provided in the distribution kit) contains the template for an LPD symbiont customization image. Note that this interface is subject to change without notice. Process Software does not support customer modifications to these interfaces.
The file shows how to modify the way the LPD protocol symbiont generates the control file it sends over the network, and the name and Internet address of the server to which it connects.
|
Note: If you use user exits, you must update your source code, recompile, and relink your routines.
|
See the comments in the beginning of the file for information on compiling and linking the code properly. Install the routine by placing USER_LPD_CLIENT.EXE in the MULTINET: directory. The customized image will be used the next time the symbiont starts.
The Stream symbiont supports user exits provided in the MULTINET_ROOT:[MULTINET.EXAMPLES] directory (available only if the library and include files are installed during the MultiNet installation procedure). The Stream user exit is named USER_STREAM_CLIENT.C.
The LPD user exit takes the first parameter specified in the OpenVMS PRINT /PARAMETER= qualifier and maps it to the job classification (emulating the UNIX lpr -C option). After adding changes to an exit file, compile the file, link it with the /SHARE qualifier, and copy the resulting executable into the common directory MULTINET_COMMON_ROOT:[MULTINET].
USER_LPD_CLIENT.C supports the addition of a linefeed after a formfeed. You use logical names and print parameters to control the behavior. Use a logical name of the form MULTINET_PRINTER_queuename_NO_FFLF_DEFAULT:
queuename is the name of the queue you are using or is the * character to designate all LPD queues defined in the logical name table MULTINET_PRINTER_TABLE to execute each time MultiNet starts:
$ DEFINE/EXECUTIVE/TABLE=MULTINET_PRINTER_TABLE ...
or use the NOFFLF parameter in a print command to control the behavior for a particular queue:
$ PRINT/PARAMETERS=(NOFFLF=TRUE) filespec
The LPD and Stream symbionts have been enhanced in the following ways:
· The first 16 bytes of the work area (the per-stream data area) in the symbionts are reserved for customer use.
· The customizable psm_max_streams_v33() routine is called by the symbionts to determine the number of streams that a symbiont should initialize.
· International character set translations are supported with the shareable user exit image MULTINET:USER_TRANSLATE.EXE. After adding changes to a customizable file, compile the file and link it with the /SHARE qualifier. (You can request a sample USER_TRANSLATE.C source module from Process Software Technical Support.)
· All MultiNet LPD and stream symbionts can be configured with a remote printer or host’s domain name in addition to its IP address.
MultiNet provides a print symbiont for sending print jobs to remote TCP-connected printers. This symbiont – NTYSMB - which works in conjunction with network terminal port (NTY) devices, can be used instead of MultiNet STREAM print queues. The NTYSMB symbiont:
· Allows for user exits. See file USER_NTYSMB_CLIENT.C in the MULTINET_ROOT:[MULTINET.EXAMPLES] directory.
· Sends a form feed at the end of a job.
· Corrects timer handling in the case where the maximum timeout is reached. The timers are controlled by two values taken from the equivalence string for the MULTINET_NTYSMB_TIMERS logical name, initial and ceiling. The values for initial and ceiling are given in seconds. The initial value is how soon, after the first connection attempt fails, the symbiont is to retry the connection. On subsequent connection failures, the symbiont backs off its retries exponentially, until it’s only retrying every ceiling seconds. By default, initial is 10 seconds and ceiling is 7200 seconds (2 hours). The NTYSMB symbiont never gives up on a job. Define the logical name as:
$ DEFINE/SYSTEM/EXEC MULTINET_NTYSMB_TIMERS “initial ceiling”
· Zeros out channel information in case a write request is received when a shutdown or close is in progress.
· Fixes queue shutdown when a timed retry is outstanding and a STOP/REQUEST is issued against the queue.
· Corrects I/O synchronization problems where data could be sent to the printer out of order.
MULTINET_NTYSMB_DEBUG causes various debug options to be enabled.
MULTINET_NTYSMB_*_MAXTIMERMSG and MULTINET_NTYSMB_queuename_MAXTIMERMSG specifies the message to be issued when the connection timer hits the maximum value. One "%s" argument will be supplied in the form of the queue name.
NTY queues have the following advantages over STREAM queues:
|
Improved print formatting |
The standard OpenVMS print symbiont normally takes advantage of formatting capabilities in the OpenVMS terminal driver. These capabilities were only partially emulated by the STREAM symbiont. Because MULTINET_NTYSMB uses network terminal port devices, full print symbiont formatting is now supported. |
|
More control over queues’ devices |
The standard SET TERMINAL and queue operation commands are used to set up the NTY terminal device and MULTINET_NTYSMB print queues. System managers wanting to take advantage of the OpenVMS queue manager's Autostart capability may now do so with this new print queue support. |
|
Familiar management interface |
The NTY Control Program (NTYCP) and MULTINET_NTYSMB print symbiont are patterned after Hewlett-Packard’s LAT Control Program (LATCP) and LAT print symbiont, providing a management interface that should be familiar to many OpenVMS system managers. |
MultiNet must be started before NTY devices can be created or MULTINET_NTYSMB print queues can be initialized or started.
System managers using the OpenVMS queue manager's Autostart capability must leave Autostart disabled until after MultiNet is started and NTY devices have been set up.
To set up a print queue with MULTINET_NTYSMB:
1. Create the NTY device.
Use the NTY Control Program (NTYCP) to create the terminal device:
$ NTYCP := $MULTINET:NTYCP
$ NTYCP CREATE PORT NTYnnnn /NODE=node/port
You can invoke the NTYCP program as an OpenVMS "foreign" command, as shown above, or run in interactive mode:
$ RUN MULTINET:NTYCP
NTYCP>CREATE PORT NTYnnnn /NODE=node/port
NTYCP>EXIT
NTYCP uses standard DCL-style command parsing. The "?" help feature available in other MultiNet utilities is not available in NTYCP.
2. Set up the terminal characteristics:
$ SET TERMINAL NTYnnnn:/PERMANENT/NOBROADCAST/NOTYPEAHEAD/NOWRAP/FORM
3. Set up spooling, if desired:
$ SET DEVICE/SPOOLED=(queue-name,SYS$SYSDEVICE:) NTYnnnn
4. Initialize and start the queue:
$ INITIALIZE/QUEUE/ON=NTYnnnn:queue/PROCESSOR=MULTINET_NTYSMB/START
The following is an example of a print queue set up to an HP LaserJet printer with a JetDirect card.
$ NTYCP :=
$MULTINET:NTYCP
$ NTYCP CREATE PORT NTY1001/NODE=hp-laserjet/PORT=9100
%NTYCP-S-CREPORT, device _NTY1001: created to host 192.1.1.5, port 9100
$ SET TERMINAL/PERMANENT
NTY1001:/NOBROADCAST/NOTYPEAHEAD/NOWRAP/FORM
$ INITIALIZE/QUEUE/ON=NTY1001:
HP_LASERJET/PROCESSOR=MULTINET_NTYSMB/START
To generate a log file with NTYSMB, do the following:
$ DEFINE/SYSTEM MULTINET_NTYSMB_DEBUG 7
The equivalence string for this logical is an integer. Various bits in this value control different aspects of debug logging. A value of 7 enables full debug logging, and is the recommended setting.
Restart the queue. If the OPCOM messages are enabled, a notification is printed telling you that debugging is enabled.
To turn off the NTYSMB log file, deassign the logical and restart the NTYSMB queue(s) that were (re)started since you defined the logical because the symbiont only looks for the logical when the queue starts up.
$ DEASSIGN/SYSTEM MULTINET_NTYSMB_DEBUG
The log files are created in MULTINET_SPOOL:NTYSMB_DEBUG_pid.LOG
pid is the hexadecimal process ID of the symbiont process in question. There may be as many as 16 queues sharing the same log file, since log files are per symbiont process, not per queue, and each process can support processing for up to 16 queues.
Since these log files are intended to assist Process Software in deciphering problems, their output might not make sense to you.
This section describes potential print queue problems and recommended solutions.
· When executing REMOTE-PRINTER-QUEUES.COM, the following messages may appear:
%SET-E-NOTSET, error
modifying NLPx:
-SYSTEM-W-DEVASSIGN, device has channels assigned
%SET-E-NOTSET, error modifying NLPx
-CLI-E-DEVALSPL, device already spooled
%JBC-I-QUENOTMOD, modifications not made to running queue4
These messages occur when the command file tries to modify an existing queue. The messages are only warnings and do not affect the queues in any way.
· Another situation may occur where the print job is "stair-stepping" down the page. It appears as if the job contains carriage line feeds, but no carriage returns.
o If the queue is set up as an LPD queue pointing to a printer, the wrong remote queue name has been specified in the printer configuration. Check the documentation for the printer's Ethernet card for the correct remote queue name. (See the Configuring an LPD Print Queue section.)
o If the queue is set up as a STREAM queue pointing to a Hewlett-Packard LaserJet, the problem is the line termination setting on the printer. Most HPLJ printers are initially configured with line termination set to <LF>=<LF>. For printing from VMS systems, the line termination should be set to <LF>=<LF>+<CR>. Consult the printer documentation about changing this parameter.
· The print job prints all on one line.
If this is a STREAM queue pointing to a printer connected to a terminal server, the terminal server characteristics must be modified. Check the terminal server documentation for the proper commands and instructions for logging onto the terminal server. The following example shows the commands for a Hewlett-Packard 90TL terminal server.
CHANGE PORT port#
TELNET SERVER NEWLINE TO HOST <CRLF>
CHANGE PORT port# TELNET SERVER NEWLINE FROM TERMINAL <CRLF>
· The queue prints text properly, but graphics do not print correctly.
If the TELNET negotiation option is ON, you may need to disable it with the SET SUPPRESS-TELNET parameter described in the MultiNet Administrator's Reference.
The default is to set TELNET negotiation OFF by default, unless it is using the default port 23. The following example shows how to disable TELNET negotiation.
$ MULTINET CONFIGURE/PRINTER
PRINTER-CONFIG>SEL queue-name
PRINTER-CONFIG>SET SUPPRESS-TELNET ENABLE
PRINTER-CONFIG>EXIT
Be sure all privileges are enabled; then invoke MULTINET:REMOTE-PRINTER-QUEUES.COM.
· PostScript files do not print.
When printing PostScript files, set the queue to NOFEED. Remove any FLAG pages from the queue. See the MultiNet Administrator's Reference for information about the SET NOFEED and SET FLAG commands. You should also specify that the OpenVMS form on which the job is printed be set to the maximum width, and defined with /NOWRAP and /NOTRUNC. Use the following commands to determine the characteristics of the form being used on the queue:
$ SHOW QUEUE/FORM/FULLform-name
An example of the characteristics on a form called POSTSCRIPT is shown in the following example:
Form
name Number Description
--------- ------ -----------
POSTSCRIPT (stock=DEFAULT) 3 Postscript input; white paper
/LENGTH=66 /MARGIN=(BOTTOM=6) /STOCK=DEFAULT /WIDTH=65535
To define the form with the proper characteristics, use the DEFINE/FORM command.
The IPP print symbiont is an OpenVMS print symbiont working with the OpenVMS printing subsystem to implement an IPP Client. It allows printing over a network to printers and servers that support the IPP v1.0 network printing protocol. The user interface is similar to other print symbionts in that it uses PRINT commands or system library calls to submit jobs to print queues. The IPP protocol has specific qualifier values and queue settings that must be present to allow the symbiont to function. This section describes both the configuration of IPP print queues and the use of the PRINT command. For information on submitting jobs to print queues using system library calls, see the appropriate OpenVMS documentation.
The Internet Printing Protocol solves a number of problems in existing network printing protocols; the most common is the LPD protocol, originally implemented on UNIX operating systems.
From RFC 2568:
"The Internet Printing Protocol (IPP) is an application level protocol that can be used for distributed printing on the Internet. This protocol defines interactions between a client and a server. The protocol allows a client to inquire about capabilities of a printer, to submit print jobs and to inquire about and cancel print jobs. The server for these requests is the Printer; the Printer is an abstraction of a generic document output device and/or a print service provider. Thus, the Printer could be a real printing device, such as a computer printer or fax output device, or it could be a service that interfaced with output devices."
IPP has a better error reporting capability than LPD or TELNET. It supports multi-sided printing, landscape/portrait layouts, and multiple pages per physical sheet ("number-up") printing. Because not all printer models that support IPP will support all capabilities, the IPP protocol includes a way for the symbiont to query the printer as to its capabilities before a job is sent. If the printer cannot handle a given request, the job is aborted with an error status. The error status appears in the system accounting log.
IPP uses the HTTP 1.1 protocol as its transport layer; however, it has its own reserved port number, port 631. You can use the IPP Symbiont to print to other port numbers, including the standard HTTP port (80), but you need to specify the port number as part of the printer URL if the port number is not the default IPP port number. If you are printing through a firewall this could be a factor to consider. For a full description of the IPP protocol, see the relevant RFCs listed below.
The IPP Printer Working Group has a web page with at least a partial list of printers that claim to support IPP. It is at:
http://www.pwg.org/ipp/index.html
The RFCs related to IPP v1.0 are:
|
Design Goals for an Internet Printing Protocol |
RFC 2567 |
|
Rationale for the Structure and Model and Protocol for the Internet Printing Protocol |
RFC 2568 |
|
Internet Printing Protocol/1.0: Model and Semantics |
RFC 2566 |
|
Internet Printing Protocol/1.0: Encoding and Transport |
RFC 2565 |
|
Internet Printing Protocol/1.0: Implementer's Guide |
RFC 2639 |
|
Mapping between LPD and IPP Protocols |
RFC 2569 |
Additional RFCs are referenced by these, such as the ones describing HTTP v1.1, MIME Media Types, etc. The specific RFCs are called out in the above documents.
The IPP symbiont implements a subset of the IPP v1.0 protocol consisting of all required portions and several selected optional features. Note that not all features are available on all printers; most printers implement a subset of the available protocol capabilities.
Not all printers claiming to support IPP implement IPP correctly. Some use supersets of HTTP 1.0, rather than the required HTTP 1.1. Some do unusual things with TCP/IP connections, such as having extremely short timeouts. The symbiont has been adapted to support as many of these inconsistencies as possible (see the EXPECT_LINK_CLOSURES option for an example). The symbiont may or may not behave as expected with such printers depending on your particular network characteristics and exactly what the printer manufacturer has done differently from what is specified in the RFCs. The symbiont should work with any fully compliant IPP v1.0 printer or server.
The IPP symbiont has a flexible configuration. You can supply the information in the queue setup itself, as the "/DESCRIPTION=" string which is supported by OpenVMS as part of the INITIALIZE/QUEUE command. You can supply the information in a "configuration" system logical name that the symbiont checks. You can use both, putting some information on one place, and some in the other. You can also put configuration information in one or more files and reference those files from the /DESCRIPTION string and/or "configuration" logical name (see the "/INCLUDE=" option), or even from other such files. If you have large numbers of queues making up complicated groupings with similar requirements, this flexibility can help reduce the time required to set up and maintain queues.
In addition to the basic configuration information, there are several optional logical names used to control specific behaviors. Note that the default behaviors may be adequate to your needs.
The following sections describe the various logical names, queue settings, and PRINT command options available with the IPP symbiont. In many cases there is a "Global" version, which affects all IPP symbiont queues on the system, as well as a "queue-specific" version that affects only a specified queue. PRINT command options affect only the job being submitted.
These logical names establish configuration values for all queues on the system, not on a queue-by-queue basis. Where there are queue-specific settings related to these, these become the default values, overriding any built-in defaults.
MULTINET_IPP_CONFIG
Specifies one or more of the qualifiers described in the Queue-specific Settings section. These qualifiers are not case sensitive. Underscores (_) in the qualifier names are optional. Each may be abbreviated as long as the result is not ambiguous. There is no default. This logical provides defaults that may be overridden by the queue-specific configuration logical, MULTINET_IPP_queuename_CONFIG, for a given queue.
MULTINET_IPP_DEFAULT_DOCUMENT_FORMAT
Specifies a string to use as the document format, unless specified differently for a given queue or print job. The actual document format used on a given job must be a valid MIME media type, supported by the printer to which the job is sent. The default is "text/plain".
MULTINET_IPP_DOCALIAS_FILE
Specifies document format name aliasing. Rather than having to specify long mime-media-type names for document formats, you can define local names that are equivalent, and the symbiont will do the replacement. For example, you can define “PS” as equivalent to “application/postscript”, and use it in print commands as /DOCUMENT_FORMAT=PS. There is an escape mechanism in case a logical name is ever made into a different MIME-media-type. Prefixing the document format name with % prevents alias translation. %PS means just send it as PS, do not translate PS into APPLICATION/POSTSCRIPT in the request.
To use aliasing, define the system logical name MULTINET_IPP_DOCALIAS_FILE with the filename of the alias file as the equivalence string. The format of the alias file is:
MULTINET_IPP_mime-name
Blank lines are ignored. Lines starting with # are treated as comments and are ignored. Document format name aliasing has been added. Rather than having to specify long mime-media-type names for document formats, you can now define local names that are equivalent, and the symbiont will do the replacement. For example, you can define "PS" as equivalent to "application/postscript", and use it in print commands such as /DOCUMENT_FORMAT=PS.
There is an "escape mechanism" in case a local name is ever made into a different MIME-media-type. Prefixing the document format name with "%" prevents alias translation. "%PS" means "just send it as 'PS', don't translate "PS" into "application/postscript" in the request.
To use aliasing, define the system logical name MULTINET_IPP_DOCALIAS_FILE with the filename of the alias file as the equivalence string.
The format of lines in the alias file is:
Mime-name: alias, alias, alias...
Blank lines are ignored, and lines starting with "#" are treated as comments and are ignored.
MULTINET_IPP_IGNORE_DESCRIPTION
MULTINET_IPP_queuename_IGNORE_DESCRIPTION
If this logical is defined, the symbiont ignores the /DESCRIPTION strings for all IPP queues. This allows use of /DESCRIPTION for other information without affecting the symbiont. Configuration of the symbiont must be done through use of the MULTINET_IPP_CONFIG logical, or the queue-specific logical, MULTINET_IPP_queuename_CONFIG if MULTINET_IPP_IGNORE_DESCRIPTION is defined. The value of the equivalence string for MULTINET_IPP_IGNORE_DESCRIPTION is not important. The existence or non-existence of the logical is all that is checked. This logical provides defaults that may be overridden by the queue-specific configuration logical, MULTINET_IPP_queuename_IGNORE_DESCRIPTION, for a given queue.
MULTINET_IPP_JOB_RETRY_DELAY
Specifies, as an OpenVMS delta time specification, the length of time to hold a job when it is re-queued due to a temporary problem. The default value is "0 00:10:00.00" (10 minutes).
MULTINET_IPP_MAX_LOG_BYTES
Specifies how many bytes of data will be logged by the send and receive routines when running with logging level set to DETAILED_TRACE. The value is an integer. A negative value sets the limit to infinite (all data will be logged). A value of zero turns off inclusion of data to the log file. A positive value sets the actual number of bytes logged, and any additional data is ignored. The default action is to log all data.
MULTINET_IPP_MAX_STREAMS
Specifies the number of streams (queues) that each IPP symbiont process can handle. This is an integer from 1 to 16. The default is 16.
MULTINET_IPP_LOG_LEVEL
Specifies one of the logging level values listed in the logging level table below, and is used to determine how serious a message must be before it is written to the log file. Only those messages marked as this level, or as a more serious level, are logged. The default is JOB_TRACE.
MULTINET_IPP_LOGFILE
Specifies the name of the log file. All queues for a given symbiont process will share this file unless there are individual queue overrides. The default is to create the log file in the default spool directory, with the name IPP_SYMBIONT_pid.LOG.
MULTINET_IPP_OPCOM_LEVEL
Specifies one of the logging level values listed in the logging level table below, and is used to determine how serious a message must be before it is sent to OPCOM. Only those messages marked as this level, or as a more serious level, are sent. The default is INFO.
MULTINET_IPP_OPCOM_TERMINAL
Specifies the OPCOM operator "terminal" to send OPCOM messages to. Permissible values are listed later in this section. The default is the PRINT operator.
These items are specified as qualifiers in the queue's /DESCRIPTION string, and/or in the MULTINET_IPP_queuename_CONFIG logical equivalence string - the two are concatenated before being processed. These qualifiers are not case sensitive. The underscores in the qualifier names are optional. Each may be abbreviated as long as the result is not ambiguous. The two sections below contain the complete list of qualifiers.
/PRINTER_URI
A valid URI, or list of URIs, for the printer or printers to be sent to from this queue. Wildcards are allowed ("*" to match one or more characters, "?" for a single character). The individual URIs in the list are separated from each other with the vertical bar ("|") character. The first URI in the list that does not include any wildcards is the default printer for the queue. If there are no default printer URIs and you have not specified a particular printer URI with the PRINT command, the job is aborted. Any printer URI specified with the PRINT command must match at least one of the URIs listed for the queue or the job will be aborted.
/COMMENT=quoted string
Allows inclusion of a quoted string of text that the symbiont will ignore, other than to write to the log file and/or OPCOM if the logging level is set to SYMBIONT or a more detailed setting.
/COPIES_DEFAULT=number
Specifies the number of copies of each document to print unless specified otherwise on the PRINT command. The default value is 1.
/DEBUG
Causes the symbiont to retain all spool files and to force DETAILED_TRACE logging to the log file, regardless of what other settings might be specified. Note that /DEBUG forces the setting for MAX_LOG_BYTES to a minimum of 512 bytes. You can set it higher, but any setting lower than 512 bytes will be ignored when /DEBUG is used.
/DEFAULT_DOCUMENT_FORMAT=formatspec or
/DOCUMENT_FORMAT_DEFAULT=formatspec
Specifies the default document format for the queue. This value will be a MIME media type that is supported for the printer or printers served by this queue. It could also be the string "***printer_default***", which will result in whatever the target printer defines as its default when no document format is specified on the PRINT command.
/EXPECT_LINK_CLOSURES
Specifies that the printer is not fully HTTP 1.1 compliant because it does not support persistent connections, and does not send a "Connection: Close" header line in its last response. Therefore, the symbiont should assume that such a line was sent in every response, using a new link for each request, closing the old one, and not treating it as an error if the other end closes the link after sending a response.
/FINISHINGS_DEFAULT=keyword
Specifies finishing operations to be performed on the printed documents. May or may not be supported by a given IPP server. Any or all of the four available finishings may be specified. Case is ignored. Keywords are:
NONE
STAPLE
PUNCH
COVER
BIND
/[NO]FLAG_DEFAULT
Specifies whether a job-sheets
attribute will be specified for jobs by default. If
/FLAG_DEFAULT is used, job-sheets
will be requested as “standard”. If /NOFLAG_DEFAULT
is used, job-sheets will be requested as “none”.
/INCLUDE=filename
Specifies a sequential access text file containing additional qualifiers from this list. These qualifiers are read and processed at the point where the /INCLUDE qualifier is encountered, and share the precedence of that point.
/JOB_PRIORITY_DEFAULT=integer
Specifies the priority of the print job. 1 is the lowest, 100 is the highest.
/JOB_RETRY_DELAY=deltatime
Specifies, as an OpenVMS delta time specification, the length of time to hold a job when it is re-queued due to a temporary problem. The default value is "0 00:10:00.00" (10 minutes).
/LOG_FILE=filename
Specifies the name of the queue log file to write messages to for this queue. The default is in MultiNet's default spool directory, unless overridden by a global setting, as described in Global Settings. The default filename is IPP_SYMBIONT_Process_PID.LOG.
/LOG_LEVEL=logging_level
Specifies one of the Logging Levels values listed in the table below, and is used to determine the severity of a message before it is written to the queue log file. Only those messages marked as this level, or a more serious one, are logged. The default is JOB_TRACE unless overridden by a global MULTINET_IPP_LOG_LEVEL logical.
/MAX_LOG_BYTES=number
Specifies how many bytes of data will be logged by the send and receive routines when running with logging level set to DETAILED_TRACE. The value is an integer. A negative value sets the limit to infinite (all data will be logged). A value of zero turns off inclusion of data to the log file. A positive value sets the actual number of bytes logged, and any additional data is ignored. The default action is to log all data.
/MEDIA_DEFAULT=name
This attribute identifies the medium that the printer uses for all pages of the Job.
The values for "media" include medium-names, medium-sizes, input-trays and electronic forms. See your printer documentation for details concerning what values are supported for your printer.
Standard keyword values are taken from ISO DPA and the
Printer MIB and are listed in Section 14 of RFC 2566. Some servers may support
definition of locally created names as well. See
Table 16-1 for standard values for input trays. The below table contains
examples of standard names. These names include, but are not limited to the
following:
|
Name |
Description |
|
default |
The default medium for the output device |
|
iso-a4-white |
Specifies the ISO A4 white medium |
|
iso-a4-colored |
Specifies the ISO A4 colored medium |
|
iso-a4-transparent |
Specifies the ISO A4 transparent medium |
|
na-letter-white |
Specifies the North American letter white medium |
|
na-letter-colored |
Specifies the North American letter colored medium |
|
na-letter-transparent |
Specifies the North American letter transparent medium |
|
na-legal-white |
Specifies the North American legal white medium |
|
na-legal-colored |
Specifies the North American legal colored medium |
|
na-9x12-envelope |
Specifies the North American 9x12 envelope medium |
|
monarch-envelope |
Specifies the Monarch envelope |
|
na-number-10-envelope |
Specifies the North American number 10 business envelope medium |
|
na-7x9-envelope |
Specifies the North American 7x9 inch envelope |
|
na-9x11-envelope |
Specifies the North American 9x11 inch envelope |
|
na-10x14-envelope |
Specifies the North American 10x14 inch envelope |
|
na-number-9-envelope |
Specifies the North American number 9 business envelope |
|
na-6x9-envelope |
Specifies the North American 6x9 inch envelope |
|
na-10x15-envelope |
Specifies the North American 10x15 inch envelope |
|
executive-white |
Specifies the white executive medium |
|
folio-white |
Specifies the folio white medium |
|
invoice-white |
Specifies the white invoice medium |
|
ledger-white |
Specifies the white ledger medium |
|
quarto-white |
Specified the white quarto medium |
|
iso-a0-white |
Specifies the ISO A0 white medium |
|
iso-a1-white |
Specifies the ISO A1 white medium |
|
a |
Specifies the engineering A size medium |
|
b |
Specifies the engineering B size medium |
|
c |
Specifies the engineering C size medium |
|
d |
Specifies the engineering D size medium |
|
e |
Specifies the engineering E size medium |
The following standard values are defined for input-trays:
|
Name |
Description |
|
top |
The top input tray in the printer. |
|
middle |
The middle input tray in the printer. |
|
bottom |
The bottom input tray in the printer. |
|
envelope |
The envelope input tray in the printer. |
|
manual |
The manual feed input tray in the printer. |
|
large-capacity |
The large capacity input tray in the printer. |
|
main |
The main input tray |
|
side |
The side input tray |
/MULTIPLE_DOCUMENT_HANDLING_DEFAULT=keyword
This qualifier is relevant only for jobs consisting of two or more documents, and when the IPP server supports jobs with multiple documents. The qualifier controls finishing operations and the placement of one or more pages onto media sheets. When printing multiple copies, it also controls the order in which the copies that result are produced. Standard keyword values are:
single-document
If a job has multiple documents, say, the documents are called A and B, then the result printing the data (A and then B) will be treated as a single sequence of media sheets for finishing operations; that is, finishing would be performed on the concatenation of the two documents. The printer will not force the data in each document to start on a new page.
If more than one copy is requested, the ordering of the pages resulting from printing will be A, B, A, B, ..., and the printer will force each copy (A, B) to start on a new media sheet.
separate-documents-uncollated-copies
If a job has multiple documents, say, the documents are called A and B, then the result of printing each document will be treated as a single sequence of media sheets for finishing operations; that is, the documents A and B would each be finished separately. The printer will force each copy of the data in a single document to start on a new sheet.
If more than one copy is made, the ordering of the pages will be A, A, ..., B, B ... .
separate-documents-collated-copies
If a job has multiple documents, say, A and B, then the result will be that each document will be treated as a single sequence of media sheets for finishing operations; that is, A and B would each be finished separately. The printer will force each copy of the result of processing the data in a single document to start on a new sheet.
If more than one copy is made, the ordering of the documents will be A, B, A, B,... .
single-document-new-sheet
Same as single-document, except that the printer will ensure that the first page of each document in the job is placed on a new media sheet.
The single-document value is the same as separate-documents-collated-copies with respect to ordering of print-stream pages, but not media sheet generation, since single-document will put the first page of the next document on the back side of a sheet if an odd number of pages have been produced so far for the job, while separate-documents-collated-copies always forces the next document or document copy on to a new sheet. In addition, if the finishings attribute specifies staple, then with single-document, documents A and B are stapled together as a single document with no regard to new sheets, with single-document-new-sheet, documents A and B are stapled together as a single document, but document B starts on a new sheet, but with separate-documents-uncollated-copies and separate-documents-collated-copies, documents A and B are stapled separately.
|
Note: None of these values provide means to produce uncollated sheets within a document, i.e., where multiple copies of sheet n are produced before sheet n+1 of the same document.
|
/NUMBER_UP_DEFAULT=number
Specifies the number of page images to be placed on each side of each sheet of paper. The number must be an integer that is acceptable to the IPP server. If the number specified is not a value supported by the server, the job aborts.
/OPCOM_LEVEL=logging_level
Specifies one of the logging level values listed in the table below, and is used to determine the severity of a message before it is sent to OPCOM. Only those messages marked as this level, or at a more serious level, are sent. The default is INFO unless overridden by a global MULTINET_IPP_OPCOM_LEVEL logical.
/OPCOM_TERMINAL=opcom_term
Specifies which OPCOM operator "terminal" to send OPCOM messages to. Available values are listed in the OPCOM Terminal Names table below. The default is the PRINT operator. See the OpenVMS documentation for the REPLY/ENABLE command for more information on OPCOM terminals.
/ORIENTATION_DEFAULT=keyword
Specifies the default page orientation. Case is ignored. Supported values are:
PORTRAIT
REVERSE_PORTRAIT
LANDSCAPE
REVERSE_LANDSCAPE
/PAGE_RANGE_DEFAULT="range[,range]..."
Specifies the page numbers to print. range is either a single integer page number, or a pair of page numbers, separated by a hyphen. Multiple range specifications are separated by commas. For example:
$ PRINT/QUEUE=IPP_QUEUE/PARAM=(PAGE_RANGES="1,3-6,9,10 ,12-14") TEST.TXT
The example specifies the pages: 1, 3, 4, 5, 6, 9, 10, 12, 13, and 14. Note that embedded spaces are allowed, and ignored.
/QUALITY_DEFAULT=keyword
Specifies the quality of the printed material. Case is ignored. The keywords are:
DRAFT
NORMAL
HIGH
/SIDES_DEFAULT=keyword
Specifies how the printing is to be placed on the paper.
· ONE-SIDED: prints each consecutive page upon one side of consecutive media sheets.
· TWO-SIDED-LONG-EDGE: prints each consecutive pair of pages upon the front and back sides of consecutive media sheets, with the orientation of each pair of pages on the long edge. This positioning is called “duplex” or “head-to-head” also.
· TWO-SIDED-SHORT-EDGE: prints each consecutive pair of pages upon front and back sides of consecutive media sheets, with the orientation of each pair of print-stream pages on the short edge. This positioning is called “tumble” or “head-to-toe” also.
/SPOOL_DIRECTORY=dirspec
Specifies the directory to use for storing temporary files used while processing print jobs for the queue. The default is MultiNet's default spool directory.
The various logicals and qualifiers described in the previous two sections sometimes define the same configuration item. The operation has been defined, but the precedence has not. The order, from lowest precedence to highest, is:
1. Built-in hard coded default values.
2. Global logicals, as described in the first section.
3. Queue-specific qualifiers found in the /DESCRIPTION string of the queue.
4. Queue-specific qualifiers found in the queue-specific CONFIG logical.
The queue-specific qualifiers are parsed second, allowing for an override of the global settings on a queue-by-queue basis when that behavior is desired.
Print command options are specified using the OpenVMS standard /PARAMETERS qualifier. The list of options is enclosed in parenthesis. For example,
$ PRINT /QUEUE=IPP_PRINTER_1 /PARAMETER=(COPIES=3, ORIENTATION=LANDSCAPE) FILE.TXT
These options are not case sensitive. The underscores in the option names are optional. Each may be abbreviated as long as the result is not ambiguous. The available print command options are:
PRINTER=printer_uri
Specifies the target printer when the queue default is not desired, or when there is no queue default. The printer URI specified must match at least one of the defined printer_uri's for the print queue.
Wildcards cannot be used in the printer URI.
COPIES=number
Specifies the number of copies of each document to print. The default value is 1.
SIDES=keyword
Specifies how the printing is to be placed on the paper. The keyword must be one of the following:
· ONE-SIDED or 1sided: prints each consecutive page upon one side of consecutive media sheets.
· TWO-SIDED-LONG-EDGE or two-long-edge or 2long_side: prints each consecutive pair of pages upon the front and back sides of consecutive media sheets, with the orientation of each pair of pages on the long edge. This positioning is called “duplex” or “head-to-head” also.
· TWO-SIDED-SHORT-EDGE or two-short-edge or 2short_side: prints each consecutive pair of pages upon front and back sides of consecutive media sheets, with the orientation of each pair of print-stream pages on the short edge. This positioning is called “tumble” or “head-to-toe” also.
ORIENTATION=keyword
Specifies the page orientation. The keyword must be one of:
PORTRAIT
REVERSE_PORTRAIT
LANDSCAPE
REVERSE_LANDSCAPE
These can be abbreviated to any non-ambiguous prefix. Case is ignored.
[NO]FLAG
Requests, or suppresses, the printing of an IPP flag page for the job. The printer may, or may not, respond to this request. The exact format of this flag page is up to the IPP Server (printer) implementation.
NUMBER_UP=number
Specifies the number of page images to be placed on each side of each sheet of paper. The number must be an integer that is acceptable to the IPP server. If the number specified is not a value supported by the server, the job aborts.
DOCUMENT_FORMAT=MIME-media-type
DOCUMENT_FORMAT=***printer_default***
Specifies the document format of the files in the job, or specifies use of the printer's built-in default. The default for this qualifier is the default for the queue. Also, if the queue configuration does not specify a default document format, the hard coded default is "text/plain".
JOB_PRIORITY=integer
Specifies the priority of the print job at the IPP server (not to be confused with the OpenVMS queue priority). 1 is the lowest, 100 is the highest.
FINISHINGS=“keyword[,keyword]...”
Specifies finishing operations to be performed on the printed documents. May or may not be supported by a given IPP server. Any or all of the four available finishings may be specified. Case is ignored.
BIND
COVER
PUNCH
STAPLE
MULTIPLE_DOCUMENT_HANDLING=keyword
Specifies how you want the printer to print your job. The keyword is one of the following:
· Single_Document or 1Document
· Separate_Documents_Uncollated_Copies or UncollatedSeparate
· Separate_Documents_Collated_Copies or CollatedSeparate
· Single_Document_New_Sheet or NewSheet
Case is ignored. See /MULTIPLE_DOCUMENT_HANDLING_DEFAULT in this chapter for information on single document, separate-documents-uncollated-copies, separate-documents-collated-copies, and single-document-new-sheet handling.
PAGE_RANGES="range[,range]..."
Specifies the page numbers to print. range is either a single integer page number, or a pair of page numbers, separated by a hyphen. Multiple range specifications are separated by commas and enclosed in double quotes.
For example:
$ PRINT/QUEUE=IPP_QUEUE/PARAM=(PAGE_RANGES="1,3-6, 9, 10, 12-14") FILE.TXT
Note that embedded spaces are allowed, and ignored. The example specifies the pages: 1, 3, 4, 5, 6, 9, 10, 12, 13, and 14.
MEDIA=name
This attribute identifies the medium that the Printer uses for all pages of the Job.
The values for "media" include medium-names, medium-sizes, input-trays and electronic forms. See your printer documentation for details concerning what values are supported for your printer.
Standard keyword values are taken from ISO DPA and the Printer MIB and are listed in section 14 of RFC 2566. Some servers may support definition of locally created names as well.
See the tables earlier in this chapter for the standard media names.
QUALITY=keyword
Specifies the quality of the printed material. Case is ignored. The keyword choices are:
DRAFT
HIGH
NORMAL
Several of the configuration and job submission settings require values for OPCOM terminal names or logging severity levels. This section defines the allowable values for these options.
|
CARDS |
NETWORK |
OPER3 |
OPER9 |
All values may be abbreviated to any non-ambiguous prefix. These values are not case sensitive.
|
DETAILED_TRACE |
All events |
|
FILE |
Events related to processing of individual files |
|
JOB |
Events related to processing of individual jobs |
|
SYMBIONT |
Events related to the state of the symbiont |
|
INFO |
Events providing information about non-error conditions |
|
WARNING |
Events warning of potential problems that do not halt processing |
|
ERROR |
Events reporting an error that prevented processing of a job |
|
FATAL |
Events reporting an error that stopped a queue |
|
ABORT |
Events reporting an error that caused the symbiont to exit |
There are a few messages that are marked to be reported regardless of the setting of the various OPCOM and log file severity levels. These are kept to a minimum, but are considered to be important enough to override the logging level settings. These cannot be suppressed.
This section provides examples of using logicals to define
queue configuration prior to queue initialization. This method can be used both
as an alternative to and in addition to the
/DESCRIPTION string shown in the previous
examples. See the Configuration section for a complete description of
all available qualifiers.
Creating an IPP symbiont queue is done using the OpenVMS INITIALIZE/QUEUE command. All standard qualifiers are allowed, but the /DESCRIPTION qualifier has special use with the IPP symbiont. See the Configuration section.
Set up an IPP symbiont queue named ENG_PRINTER to obtain its configuration information from a queue specific configuration file and to print a flag page with each job.
$ DEFINE/SYSTEM
MULTINET_IPP_ENG_PRINTER_CONFIG -
_$ "/INCLUDE=SYS$SYSTEM:ENG_PRINTER.SETUP/FLAG_DEFAULT"
$ INITIALIZE/QUEUE/PROCESSOR=MULTINET_IPP_SYMB
ENG_PRINTER
The file SYS$SYSTEM:ENG_PRINTER.SETUP contains:
/printer="ipp://engprinter.example.com:631/ipp"
Set up the IPP symbiont queues named IPP_PRINT_QUEUE and IPP_PRINT_2 to print only to the iprinter.example.com printer on port 631. Additionally, IPP_PRINT_2 will always print two copies of each submitted file if copies are supported by the printer.
$ DEFINE/SYSTEM
MULTINET_IPP_CONFIG -
_$ "/PRINTER_URI=""ipp://iprinter.example.com:631/ipp"""
$ INITIALIZE/QUEUE /PROCESSOR=MULTINET_IPP_SYMB
IPP_PRINT_QUEUE
$ INITIALIZE/QUEUE /PROCESSOR=MULTINET_IPP_SYMB -
_$ /DESCRIPTION="/copies_default=2"
IPP_PRINT_2
Set up an IPP symbiont queue to print to any IPP printer in the example.com domain, with the default printer being iprinter.example.com:
$ INITIALIZE/QUEUE
/PROCESSOR=MULTINET_IPP_SYMB /DESCRIPTION="/printer=
""http://iprinter.example.com:631/ipp|*.example.com"""
IPP_PRINT_QUEUE
Set up two IPP symbiont queues to print to any printer in the example.com domain, with the default printer being iprinter.example.com for one queue, and oprinter.example.com for the other. Log all possible messages to the log file, but send only messages more severe than FILE_TRACE to OPCOM. Use a 5 minute retry delay, and make the document format default the same as the printer's default. Use a disk file for the configuration information common to both queues:
$ INITIALIZE/QUEUE
/PROCESSOR=MULTINET_IPP_SYMB -
_$ /DESCRIPTION="/printer=
""http://iprinter.example.com:631/ipp|*.example.com""
/include=SYS$SYSTEM:IPP_QUEUE.SETUP" IPRINTER_QUEUE
$ INITIALIZE/QUEUE
/PROCESSOR=MULTINET_IPP_SYMB -
_$ /DESCRIPTION="/printer=
""http://oprinter.example.com:631/ipp|*.example.com""
/include=SYS$SYSTEM:IPP_QUEUE.SETUP"
OPRINTER_QUEUE
The file SYS$SYSTEM:IPP_QUEUE.SETUP contains:
/log_level=DETAILED_TRACE
/opcom_level=FILE_TRACE
/job_retry_delay="0 00:05:00.00"
/default_document_format=***printer_default***
Do the same as the prior example, but put as much of the configurations in disk files as possible to allow changes to queue characteristics without having to re-initialize the queues:
$ INITIALIZE/QUEUE
/PROCESSOR=MULTINET_IPP_SYMB -
_$ /DESCRIPTION="/INCLUDE=SYS$SYSTEM:IPP_IPRINTER.SETUP"
IPRINTER_QUEUE
$ INITIALIZE/QUEUE
/PROCESSOR=MULTINET_IPP_SYMB -
_$ /DESCRIPTION="/INCLUDE=SYS$SYSTEM:IPP_OPRINTER.SETUP"
OPRINTER_QUEUE
The file SYS$SYSTEM:IPP_IPRINTER.SETUP contains:
/printer="http://iprinter.example.com:631/ipp|*.example.com"
/include=SYS$SYSTEM:IPP_QUEUE.SETUP
The file SYS$SYSTEM:IPP_OPRINTER.SETUP contains:
/printer="http://oprinter.example.com:631/ipp|*.example.com"
/include=SYS$SYSTEM:IPP_QUEUE.SETUP
The file SYS$SYSTEM:IPP_QUEUE.SETUP contains:
/log_level=DETAILED_TRACE
/opcom_level=FILE_TRACE
/job_retry_delay="0 00:05:00.00"
/default_document_format=***printer_default***
This section describes how to submit jobs to the IPP symbiont print queues.
Print the file FOO.TXT to the IPRINTER (default destination printer) set up in the prior examples:
$ PRINT/QUEUE=IPRINTER_QUEUE foo.txt
Print a single text file to a non-default printer on a queue with a wild carded printer URL:
$ PRINT
/QUEUE=iprinter_queue -
_$ /PARAM=(printer="ipp://another.example.com/ipp/port1")
foo.txt
|
Note: The above will fail unless the queue specifies another.example.com as a legal URL, either explicitly or by using wildcards.
|
Print a text file to a default printer on a queue but specify the document format and additional copies:
$ PRINT /QUEUE=iprinter_queue /PARAM=(document="plain/text",copies=3) foo.txt
The MULTINET IPP SHOW utility allows a user to learn the capabilities supported by an IPP server. The command syntax is:
$ MULTINET IPP SHOW server_URI /qualifiers...
Refer to the MultiNet Administrator’s Reference Guide, Chapter 1, for details.