If you specify background mounting, you should also use the /RETRIES qualifier with a small non-zero number. This qualifier sets the number of of times the transaction itself should be retried. Specify background mounting, along with the desired delay time and retry count parameters, with the /BACKGROUND=[DELAY:OpenVMS_delta_time, RETRY:n qualifier. For example, the following command attempts to mount in background mode, on local device DNFS4:, the file system /flyer, which physically resides on host migration. If the mount fails, the NFS client waits 1 minute and retries the connection up to 20 times.
UCX> MOUNT DNFS4: /HOST="migration" /PATH="/flyer" - _UCX> /BACKGROUND=(DELAY:00:01:00, RETRY:20) /RETRIES=4
Overmounting allows you to mount another path onto an existing mount point. Specify overmounting with the /FORCE qualifier. The client dismounts the original mount point and replaces it with a new one.
Mounting a higher or lower directory level in a previously used path is also an overmount. For example, an overmount occurs when you execute two MOUNT commands in the following order:
UCX> MOUNT DNFS123:[USERS.MNT] /HOST="robin" /PATH="/usr" %DNFS-S-MOUNTED, /usr mounted on _DNFS123:[USERS.MNT] UCX> MOUNT DNFS123:[USERS.MNT] /HOST="robin" - _UCX> /PATH="/usr/tern" /FORCE %DNFS-S-REMOUNTED, _DNFS123:[USERS.MNT] remounted as /usr/tern on ROBIN
The second MOUNT command specifies a lower level in the server path.
This constitutes another path name and qualifies for an overmount.
15.3.5 Occluded Mounting
Occluded mounting allows you to mount a file system onto a client mount point that is higher or lower in the directory structure than an existing, active mount. This is different from overmounting because dismounting does not occur. Instead, the client occludes (hides from view) the subdirectory (or subdirectories) added to or dropped from the original mount specification when you perform a directory listing.
Specify an occluded mount with the /FORCE qualifier.
In the following example, the mount point specification was "backed up" one subdirectory from the previous one. If you issue the SHOW MOUNT command, both mounts are visible. However, if you issue DIRECTORY for DNFS2:[USERS.SPARROW], [.MNT] is no longer visible. To make this subdirectory visible again, issue the DISMOUNT command to dismount DNFS2:[USERS.SPARROW].
UCX> MOUNT DNFS2:[USERS.SPARROW.MNT] /HOST="birdy" /PATH="/usr" %DNFS-S-MOUNTED, /usr mounted on _DNFS2:[USERS.SPARROW.MNT] UCX> MOUNT DNFS2:[USERS.SPARROW] /HOST="birdy" /PATH="/usr" /FORCE %DNFS-S-MOUNTED, /usr mounted on _DNFS2:[USERS.SPARROW] -UCX-I-OCCLUDED, previous contents of _DNFS2:[USERS.SPARROW] occluded
The following example shows a mount of UNIX directory /usr to the OpenVMS device and directory DNFS3:[0,0].
On the UNIX host, the directing listing looks like this:
unix% ls grebe wings pratincole
To do the mount, issue:
$ UCX MOUNT DNFS3: /HOST="unix" /PATH="/usr"
To check that the mount succeeded, issue:
$ UCX SHOW MOUNT DNFS3: /FULL . . .
On the OpenVMS host, the directory listing looks like this:
$ DIRECTORY [0,0] Directory DNFS3:[000,000] GREBE.DIR;1 WINGS.DIR;1 PRATINCOLE.DIR;1 Total of 3 files.
Additional qualifiers to the MOUNT command are described in the DIGITAL TCP/IP Services for OpenVMS Management Command Reference manual.
Part 5 describes how to set up and manage the printing services available with DIGITAL TCP/IP Services for OpenVMS (UCX).
Chapter 16 describes how to set up LPR/LPD, providing access to local and remote print queues.
Chapter 17 describes how to set up and manage the TELNET print symbiont (TELNETSYM). TELNETSYM provides remote print services that enable the use of standard OpenVMS printing features not available with LPR/LPD.
Chapter 18 describes how to set up and manage printing for PC-NFS client users.
The LPR/LPD service allows other network hosts to access queues on the server system and provides local access to queues on remote hosts. The remote print server and the client hosts must run Version 4.2 (or later) of the Berkeley Software Distribution line printer spooler software (lpd).
The line printer daemon (LPD) controls all printers and handles the following tasks:
This chapter describes how to set up and manage the LPR/LPD printing
service available with the DIGITAL TCP/IP Services for OpenVMS product.
See the DIGITAL TCP/IP Services for OpenVMS User's Guide for general usage information and complete
command descriptions.
16.1 Reviewing Key Concepts
The LPR/LPD service allows other network hosts to access queues on the server system and provides local access to queues on remote hosts. The line printer daemon (LPD) is activated when you enter a print or LPR command. The daemon copies the file to the printer's spool directory and prints requests in the order in which they entered the queue. A copy of the file to be printed remains in the queue until the printer is ready to print it; then the LPD daemon removes the file from the spooling queue and sends it to the printer.
LPD uses the printcap database to process print requests. The printcap database, located in SYS$SPECIFIC:[UCX_LPD]:UCX$PRINTCAP.DAT, is an ASCII file that defines the print queues. The printcap entries are similar in syntax to the entries in a UNIX /etc/printcap file.
You configure printers by manually editing the printcap database and by creating the necessary spool directories and log files. Section 16.3.1 describes how to manually configure printers.
Alternately, you can use the printer setup program LPRSETUP to
configure or modify printers. The setup program creates spool
directories and log files based on the information you supply.
Section 16.3.2 describes how to use the printer setup program to
configure printers.
16.2 Configuring LPR/LPD
If you use the configuration procedure to configure LPR/LPD, the procedure completes the following tasks:
Logical Name | Description |
---|---|
UCX$LPD_PRINTCAP | Database that maps queues and makes queues available |
UCX$LPD_SPOOL | Main spooling directory |
UCX$LPD_RETRY_INTERVAL | For outbound print jobs, time period between retries to print |
UCX$LPD_MAXIMUM_INTERVAL | For outbound print jobs, maximum time period that LPD retries to print if repeatedly unsuccessful |
UCX$LPD_LOGFILE | Name of the log file for the UCX$LPD_QUEUE which precedes all inbound jobs |
UCX$LPD_PS_EXT |
Database that maps PS extensions
Used to configure system wide PostScript options. Values for this logical name are as follows:
|
LPD uses the printcap database to process print requests. The printcap database, located in SYS$SPECIFIC:[UCX_LPD]:UCX$PRINTCAP.DAT, is an ASCII file that defines the print queues. The printcap entries are similar in syntax to the entries in a UNIX /etc/printcap file.
If you use the configuration procedure to configure LPD, this database is created for you. Unlike other UCX database files, you can manually edit the printcap database to add or modify printer entries. Section 16.3.1 describes how to edit the printcap database.
Alternately, you can use the printer setup program
SYS$SYSTEM:UCX$LPRSETUP.EXE to configure or modify printers. This
program creates all necessary files and directories for you.
Section 16.3.2 describes how to use the printer setup program to
configure printers.
16.3.1 Manual Configuration
Printcap database entries identify the incoming and outgoing LPD queues on the local system. Each entry provides:
Entries for outgoing jobs also identify the name of the remote host and the printer on the remote host.
Printer characteristics are specified by 2-character mnemonic symbols and values that define the printer's configuration. Table 16-2 describes the printcap symbols.
Symbol | Description |
---|---|
sd | Printer spool directory |
lf |
Specifies the error log file. This is optional. If you do not specify
an error log file, errors are logged to the operator console.
An error log can be shared by all local printers if you specify the same file in each printcap printer entry. |
lp | Name of the local printer |
ps | LPD PrintServer extensions flag |
rm | Name of the remote host |
rp | Name of the remote printer |
fm | Printer form field |
pa | /PASSALL flag |
nd | /NODELETE flag |
cr | cr flag |
p1-p8 | /PARAMETER=(p1,...,p8) field |
To make the printcap entries easier to read, use one symbol per line, placing a colon (:) at the start of each line and a colon and backslash (:\) at the end of the line to separate the symbols.
The following is a sample entry from the printcap database that identifies a local printer.
# LOCAL1|local1:\ :lf=/SYS$SPECIFIC/UCX_LPD/LOCAL1.LOG:\ :lp=LOCAL1:\ :sd=/SYS$SPECIFIC/UCX_LPD/LOCAL1:\ :nd:
The following is a sample printcap entry that identifies a remote printer.
# REMOTE1|remote1:\ :lf=/SYS$SPECIFIC/UCX_LPD/REMOTE1.LOG :\ :rp=REMOTE1 :\ :rm=HERMES :\ :sd=/SYS$SPECIFIC/UCX_LPD/ :\
Each printer must have its own spool directory located under the SYS$SPECIFIC:[UCX_LPD] directory. The spool directory acts as a printer's spooling queue; it contains the files that are queued for printing on that particular printer. A printer spool directory should have the same name as the printer reference name and must be located on the machine to which the printer is attached.
Each printer should specify a spool directory even if the printer is connected to another machine or is on another network. You specify a spooling directory in the printcap database with the sd symbol. For example,
:sd=/SYS$SPECIFIC/UCX_LPD/LOCAL1:\
The LPD daemon records printer errors in a log file located in SYS$SPECIFIC:[UCX_LPD]. You can set up a separate log file for each printer or one to be shared by all local printers.
Specify the log file in the printcap database with the symbol lf. For example, to specify a log file for the print queue named LOCAL1, the printcap entry would be as follows:
:lf=/SYS$SPECIFIC/UCX_LPD/LOCAL1.LOG:\
To specify a log file that can be shared by all printers, specify the same file for each printer entry. For example:
:lp=LOCAL1:\ :lf=/SYS$SPECIFIC/UCX_LPD/UCX_LPD_LOGFILE.LOG:\ . . . :lp=LOCAL2"\ :lf=/SYS$SPECIFIC/UCX_LPD/UCX_LPD_LOGFILE.LOG:\
You can configure LPD to support remote printing on a system that does not implement the DIGITAL PostScript extensions. You do this for individual queues by adding a ps field in the queue's printcap entry with a value of non_PS. The printcap entry looks as follows:
:rm=Remote1 :ps=non_PS
If you do not define a ps entry, LPD assumes the printer supports the DIGITAL PostScript extensions.
Note that you can also configure this option systemwide with the UCX$LPD_PS_EXT logical name. Values for this logical name are non_PS and LPS. See Table 16-1 for more information about the LPD logical names.
If a printcap entry does not have a ps field defined, LPD uses
the value you assigned with the logical name. If the logical name is
not defined, LPD uses PS extensions as the default.
16.3.2 Configuring Printers with LPRSETUP
This section describes how use the printer setup program, SYS$SYSTEM:UCX$LPRSETUP.EXE, to configure a printer directly connected to your computer. Similar to the UNIX /usr/sbin/lprsetup utility, you can also use this program to modify a printer's configuration or remove a printer.
Before running the printer setup program, you need the following information for each printer you want to configure:
The printer setup program performs the following:
Table 16-3 describes the LPRSETUP commands.
Command | Description |
---|---|
add | Adds a printer name by which you want to identify the printer through the LPR command, for example: LPR -P printername |
delete | Removes an existing printer from your configuration |
view | Displays the contents of the current printcap database |
help | Displays online help about the LPRSETUP program |
exit | Exists from the LPRSETUP program |
You can abbreviate any command option with its initial letter. Enter information at each prompt or press Return to accept the default. Enter a question mark (?) to obtain a description of the information requested at each prompt.
The following example illustrates how to use the printer setup program to configure a printer named LOCAL1.
$ SYS$COMMON:[SYSEXE]UCX$LPRSETUP.EXE UCX Printer Setup Program Command < add delete view help exit >: add Adding printer entry, type '?' for help. Enter printer name to add : LOCAL1 Enter the FULL name of one of the following printer types: remote local : Enter printer synonym: Enter full file specification for spool directory SPOOLER DIRECTORY 'sd' : [SYS$SPECIFIC:[UCX_LPD.LPD_LOCAL1]] ? Y Enter full file specification for printer log file. printer error log file 'lf' [SYS$SPECIFIC:[UCX_LPD]LPD_LOCAL1.LOG] ? Y Enter the name of the printcap symbol you wish to modify. Other valid entry is : 'q' to quit (no more changes) The names of the printcap symbols are: Enter symbol name: q Symbol type value ------ ---- ----- Error log file : lf STR /SYS$SPECIFIC/UCX_LPD/LOCAL1.LOG Printer Queue : lp STR LOCAL1 Spool Directory : sd STR /SYS$SPECIFIC/UCX_LPD/LOCAL1 Are these the final values for printer LOCAL1 ? [y] Adding comments to printcap file for new printer, type '?' for help. Do you want to add comments to the printcap file [n] ? : N *********************************************** * UCX$LPD_STARTUP.COM UCX$LPD_PRINTCAP * * and UCX$LPD_SHUTDOWN.COM * * have been updated for this printer * * * * Set up activity is complete for this printer* *********************************************** Command < add delete view help exit >: exit
The following shows how to use the printer setup program to remove a printer from the printcap database.
Command < add delete view help exit >: delete Deleting a printer entry, type '?' for help. Enter printer name to delete (or view to view printcap file): LOCAL1 Symbol type value ------ ---- ----- Error log file : lf STR /SYS$SPECIFIC/UCX_LPD/LOCAL1.LOG Printer Queue : lp STR LOCAL1 PS extensions flag: ps STR non_ps Spool Directory : sd STR /SYS$SPECIFIC/UCX_LPD/LOCAL1 Delete local1, are you sure? [n] y
To start your print queues, issue the following command
$ SYS$MANAGER:UCX$LPD_STARTUP.COM
To stop print queues, issue the following command:
$ SYS$MANAGER:UCX$LPD_SHUTDOWN.COM
To display the status of a remote queue, issue the LPQ command at the DCL prompt. To remove jobs from a remote printer queue, issue the LPRM command at the DCL prompt. See DIGITAL TCP/IP Services for OpenVMS User's Guide for more information about these commands.
The following example deletes all the jobs on remote print queue EIDER_DOWN_Q:
$ LPRM EIDER_DOWN_Q /ALL
You can grant or deny access to remote users by issuing the command SET SERVICE LPD /FLAGS=APPLICATION_PROXY. This causes LPD to authenticate remote users through the proxy database. You identify the remote users by adding communication proxy entries in the proxy database, UCX$PROXY.DAT. Each remote user allowed to access your local queues must have an entry.
To add a proxy entry, issue:
UCX> ADD PROXY user_name /HOST=host_name /REMOTE_USER=user_name
For each host, define both its host name and alias name. Use uppercase and lowercase consistently.
You may use wildcards when adding proxy entries for users on remote systems. For example, the following command allows any user on the remote host REMOTE1 to submit print jobs to the print queues on your system.
UCX> ADD PROXY R_USERS /HOST=REMOTE1 /REMOTE_USER="*"
To disable authentication, use the /FLAG=NOAPPLICATION_PROXY option to the SET SERVICE LPD command. Use the /REJECT option to deny access from certain hosts. For example,
UCX> SET SERVICE LPD /REJECT=HOSTS=(loon,ibis,tern)
The LPR/LPD spooler can notify you of selected events with OPCOM messages. To receive these notifications, issue:
$ UCX SET SERVICE LPD /LOG=OPTION $ REPLY /ENABLE=OPCOM
The logging options defined are:
LPD supports all OpenVMS FLAG PAGE print options, including:
To turn on these features, define the system logical name UCX$LPD_VMS_FLAGPAGES. At queue startup time, issue:
$ DEFINE /SYSTEM UCX$LPD_VMS_FLAGPAGES
When you define UCX$LPD_VMS_FLAGPAGES, LPD does the following:
The TELNET print symbiont (TELNETSYM) provides remote printing services that enable the use of standard OpenVMS printing features not available with the LPR/LPD print service. With TELNETSYM configured on your system, you can set up and manage a remote printer attached to a remote terminal server as if it were directly connected to your system. The TELNET symbiont functions in a manner that is similar to that of LATSYM for DIGITAL's local area transport (LAT) software.
The TELNET symbiont performs the following functions:
This chapter reviews basic TELNETSYM concepts and describes how to set
up and manage remote printers.
17.1 Reviewing Key Concepts
TELNETSYM transfers record-oriented data to and from disks and
printers. Because TELNETSYM is a true OpenVMS print symbiont, it
performs all print formatting functions, such as header and trailer
page generation, pagination, queuing, and handling of multiple forms.
17.1.1 TELNETSYM Modifications to the Output Stream
TELNETSYM modifies the print output stream as follows:
TELNETSYM sets its process names to UCX$TNSYM1, UCX$TNSYM2, and so on.
17.2 Setting Up a Print Queue
Use the DCL command INITIALIZE/QUEUE to set up a TELNETSYM queue. Use the /PROCESSOR and /ON qualifiers as follows:
For example, to set up a TELNETSYM queue named xyz_q to print to host printserver.xyz.com at TCP port 4242, issue:
$ INITIALIZE /QUEUE /PROCESSOR=UCX$TELNETSYM - _$ /ON="printserver.xyz.com:4242" xyz_q
You can redirect the output of TELNETSYM to another queue, rather than directly sending it to a remote printer. A queue with this setup is a relay queue. Use relay queues to funnel fully formatted output to an outbound LPD queue. LPD transfers jobs that are fully formatted on the sending side by OpenVMS.
TELNETSYM saves the output stream to a temporary file and then submits the file to the destination queue. TCP/IP is not used.
To set up a TELNETSYM relay queue, specify the /ON qualifier of the INITIALIZE/QUEUE command as follows, where qname is the name of the queue to which you want TELNETSYM to send its output.
/ON="UCX$QUEUE:qname"
For example, to set up a TELNETSYM relay queue named RELAYQ_4 to send output to the queue named LPD_Q4, issue:
$ INITIALIZE /QUEUE /ON="UCX$QUEUE:LPD_Q4" - _$ /PROCESS=UCX$TELNETSYM /DEVICE=PRINTER RELAYQ_4
You can manage and customize TELNETSYM for each print queue by defining logical names before you start the queue. Because the logical names are translated once at queue startup time, they can be defined differently for each TELNETSYM queue. Use the /SYSTEM qualifier when defining TELNETSYM logical names. This places the logical name in the system logical name table and makes it available to all users.
Some TELNETSYM configuration logical names are used to set a configuration option either ON or OFF. If the logical name is defined, the option is ON. If it is not defined, the option is OFF.
Other logical names require a specific value. The following sections
describe TELNETSYM logical names. Descriptions indicate when a value is
required.
17.4.1 Controlling Stream of Print Bytes Sent Over the Link
If a remote printer does not support the TELNET protocol, you can still print to such a printer by suppressing all TELNET modifications of the output stream with the logical names described below.
By default, TELNETSYM sends messages to the operator and records error and informational messages in the file UCX$TELNETSYM.LOG. This file is located in SYS$SPECIFIC:[UCX_LPD]. Logical names are available to modify the way the TELNETSYM logs information and the type of information it reports. For example, TELNETSYM can log diagnostic messages that you can use when troubleshooting problems with a link.