HP OpenVMS Systems Documentation

Content starts here

Compaq TCP/IP Services for OpenVMS

Previous Contents Index Setting Up Error Logging

The LPD records printer errors in a log file located in the SYS$SPECIFIC:[TCPIP$LPD] directory. You can set up a separate log file for each printer, or you can set up one to be shared by all local printers.

To specify the log file in the printcap database, use the symbol lf and specify the directory as a UNIX path. For example, to specify a log file for the print queue named LOCAL1, the printcap entry would be as follows:


To specify a log file that can be shared by all printers, specify the same file for each printer entry. For example:



:lf=/SYS$SPECIFIC/TCPIP$LPD/TCPIP$LPD_LOGFILE.LOG: Support for PrintServer Extensions

You can configure LPD to support remote printing on a system that does not implement the PrintServer 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:


If you do not define a ps entry, LPD assumes the printer supports the PrintServer extensions.

Note that you can also configure this option systemwide with the TCPIP$LPD_PS_EXT logical name. Values for this logical name are non_PS and LPS . See Table 22-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 PrintServer extensions as the default.

22.4 Managing LPD Server Queues

To start the LPD server queues, enter the following command:


To stop the LPD server queues, enter the following command:


To display the status of a remote queue, enter the LPQ command at the DCL prompt. To remove jobs from a remote printer queue, enter 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:


22.5 Controlling Access to Local Queues

You can grant or deny remote users access to the LPD server by entering the command SET SERVICE LPD /FLAGS=APPLICATION_PROXY. This causes LPD to authenticate remote users through the TCP/IP Services proxy database. You identify the remote users by adding communication proxy entries in the proxy database, TCPIP$PROXY.DAT. Each remote user allowed to access your local queues must have an entry.

To add a proxy entry, enter:

TCPIP> ADD PROXY user_name /HOST=host_name /REMOTE_USER=user_name

For each host, define both its host name and alias name. If you need to use lowercase letters to specify a remote user name, enclose it in quotation marks. For example:


You use wildcard characters 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.


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:


22.6 Receiving LPR/LPD OPCOM Messages

The LPR/LPD spooler can notify you of selected events with OPCOM messages. To receive these notifications, enter:


The logging options are:

  • LOGIN --- LPD receiver startup and exit
  • LOGOUT --- Job completion
  • ACTIVATE --- Queue startup

22.7 Using OpenVMS Flag Page Options

LPD supports all OpenVMS flag page print options, including:

  • /FLAG qualifier of the DCL PRINT command
  • /DEFAULT=FLAG setting on the LPD print queue
  • /SEPARATE=FLAG setting on the LPD print queue

To enable these features, define the system logical name TCPIP$LPD_VMS_FLAGPAGES. This logical name applies to all print queues:


When you define TCPIP$LPD_VMS_FLAGPAGES, LPD does the following:

  • Obeys the OpenVMS instructions regarding flag pages for outbound jobs.
  • Submits inbound jobs with /FLAG or /NOFLAG, based on the presence of the L card directive in the LPD control file received from the remote host.
    Inbound jobs with an L card directive are submitted to the destination print queue as PRINT /FLAG.
    Inbound jobs without an L card directive are submitted to the destination print queue as PRINT /NOFLAG.
  • Renders meaningless the /PARAMETERS=NOFLAG qualifer to the DCL command PRINT.

22.8 Solving LPD Problems

In addition to the log files specified in the printcap database, which is used by the LPR and LPD symbionts, the LPD receiver logs diagnostic messages to the log file TCPIP$LPD_RCV_STARTUP.LOG. Use the TCPIP$LPD_RCV and TCPIP$LPD_DEBUG logical names to control LPR/LPD diagnostic information in these logs.

Table 22-1 describes the logical names in more detail.

If you have problems, turn on all the LPR/LPD diagnostics. That is, define TCPIP$LPD_DEBUG and TCPIP$LPD_RCV as 15. Leaving these diagnostics on during normal use might affect the performance of LPD and produce large log files.

Chapter 23
Setting Up and Managing TELNETSYM

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 Compaq's local area transport (LAT) software.

The TELNET symbiont performs the following functions:

  • Transfers record-oriented data to printers.
  • Configures printers attached to terminal servers that support TELNET.
  • Supports outbound print jobs and offers standard OpenVMS preformatting for outbound print jobs.

This chapter reviews key TELNETSYM concepts and describes:

23.1 Key Concepts

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. TELNETSYM extends the OpenVMS print symbiont by redirecting its output to a network (TELNET) channel.

TELNETSYM sets its process names to TCPIP$TNSYM1, TCPIP$TNSYM2, and so on. Each TELNETSYM process can control up to 16 print queues. You can control the maximum number of print queues by defining the TCPIP$TELNETSYM_STREAMS logical, as described in Section 23.5.6.

23.1.1 TELNETSYM Modifications to the Output Stream

TELNETSYM adds escape (0xFF) bytes in the data stream so they are not mistakenly interpreted as TELNET protocol IAC commands.

TELNETSYM doubles any TELNET IAC characters found in the byte stream unless TCPIP$TELNETSYM_RAW_TCP is defined for the queue. The IAC character is a hexadecimal FF.

If the print job is queued with the /PASSALL qualifier, TELNETSYM sets up a binary TELNET channel by inserting IAC-DO-BINARY and IAC-WILL-BINARY escape sequences.

You can turn off this behavior by defining the logical name TCPIP$TELNETSYM_RAW_TCP for the queue. If you set this logical name, none of this processing is done.

The IAC-DO-BINARY sequence is 6 bytes, which are symbolically:


The hexadecimal equivalents are:


TELNETSYM does not add any additional data to the stream other than that described. It does not insert form feed characters that were not present in the output from the OpenVMS print symbiont. Therefore, any additional characters observed as added to a print job come from the OpenVMS or other print symbiont (for example, Compaq PATHWORKS/Advanced Server for OpenVMS).

TELNETSYM can remove (suppress) any form feed (0x0c) characters that the OpenVMS print symbiont adds to the beginning or end of print jobs. Use the TCPIP$TELNETSYM_SUPPRESS_FORMFEEDS logical name to control this function, as described in Section

23.2 TELNETSYM Service Startup and Shutdown

The TELNETSYM service can be shut down and started independently of TCP/IP Services. This is useful when you change parameters or logical names that require the service to be restarted.

The following files are provided:

  • SYS$STARTUP:TCPIP$TELNETSYM_STARTUP.COM allows you to start up the TELNETSYM service independently.
  • SYS$STARTUP:TCPIP$TELNETSYM_SHUTDOWN.COM allows you to shut down the TELNETSYM service independently.

To preserve site-specific parameter settings and commands, create the following files. These files are not overwritten when you reinstall TCP/IP Services:

  • SYS$STARTUP:TCPIP$TELNETSYM_SYSTARTUP.COM can be used as a repository for site-specific definitions and parameters to be invoked when the TELNETSYM service is started.
  • SYS$STARTUP:TCPIP$TELNETSYM_SYSHUTDOWN.COM can be used as a repository for site-specific definitions and parameters to be invoked when the TELNETSYM service is shut down.

23.3 Setting Up Print Queues

Use the DCL command INITIALIZE/QUEUE to set up a TELNETSYM queue. Use the /PROCESSOR and /ON qualifiers as follows:

  1. Specify the TELNETSYM image name in the /PROCESSOR qualifier, as follows:

  2. Specify the host name and port number to which the queue sends the print data with the /ON qualifier, as follows:


For example, to set up a TELNETSYM queue named xyz_q to print using TELNETSYM to host printserver.xyz.com at TCP port 4242, enter:

_$ /ON="printserver.xyz.com:4242" xyz_q

23.4 Setting Up Relay Queues

You can redirect the output of TELNETSYM to another queue rather than sending it directly 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.

In this case, TELNETSYM saves the output stream to a temporary file and then submits the file to the destination queue. TCP/IP Services 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.


To set up a TELNETSYM relay queue named RELAYQ_4 to send output to the queue named LPD_Q4, enter:


23.5 Managing and Customizing Your Print Queues

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. You must stop and restart the print queue to establish the changes you make with logical names.

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. The descriptions indicate when a value is required.

23.5.1 Controlling Stream of Print Bytes Sent Over the Link

If a remote printer supports a raw network data connection rather than the TELNET protocol, you can print to such a printer by suppressing all TELNET modifications of the output stream with the following logical names:

    Suppresses all TELNET type modifications of the print output stream.
    This logical name also prevents the TELNETSYM from doubling IAC characters and sending the TELNET escape sequence to negotiate binary options for files printed /PASSALL.

    Suppresses form feeds between jobs. This includes the form feed that is normally sent before the first job printed to a print queue and the form feed sent at the end of every job. For more information, see Section

23.5.2 Setting Up Error Logging

OPCOM messages sent by TELNETSYM include the name of the execution queue. In addition, each TELNETSYM queue has a log file named TCPIP$TELNETSYM_queue-name.LOG.

By default, TELNETSYM sends messages to the operator and records error and informational messages in the file TCPIP$TELNETSYM_queue-name.LOG. This file is located in SYS$SPECIFIC:[TCPIP$LPD].

You can use logical names 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.

Use the following logical names to modify error logging:

    Turns on the logging of TELNETSYM diagnostics to the file TCPIP$TELNETSYM.LOG. These diagnostics include informational messages that indicate when links have come up or gone down and error messages.
    Stops TELNETSYM from sending messages to the operator console.
    Used with TCPIP$TELNETSYM_VERBOSE, this logical name tells TELNETSYM which diagnostic message types to log.
    Specify a value for each bit. Each bit set in the value turns on a particular logging function. The options are:
    Bit 0 Tracks the flow of code. For example:
    xyz-n-xyz-routine entered
    Bit 1 Tracks the allocation of memory. For example:
    just freed address 7F0000
    Bit 2 Logs the bytes sent and received over TCP/IP link.

    To set a bit, assign the value to the logical name whose binary equivalent would have the bit set. For example, you can tell TELNETSYM to log everything that it writes to and receives from the TCP/IP link by entering:


    Decimal 4 is binary 100 with bit 2 set. Note that you can achieve different combinations by setting more than one bit in the value. A value of 3, for example, sets bits 0 and 1, causing logging of flow of code and memory allocation diagnostics.
    If TCPIP$TELNETSYM_DEBUG is undefined, TELNETSYM does not log these diagnostics.
    Bit 2 is useful in unassisted problem solving. Be aware, however, that the log file can become large because all the data sent over the link to the printer is logged. Bits 0 and 1 are primarily for use by Compaq. However, with knowledge of PSM$ symbionts, you might find all the options useful.
    By default, TELNETSYSM saves all log files. Define this logical name to limit the number of log files saved. The value assigned to this logical name is the number of versions of a log file TELNETSYM will allow before it starts purging. When the number of files reaches the number you specified, TELNETSYM starts purging files.
    For example, to configure the queue to purge after more than three copies of the same log file are created, define the logical name as follows:

    By default, TELNETSYM stores log files and any temporary files created by relay queues in the directory SYS$SPECIFIC:[TCPIP$LPD]. You can change the default directory for one or all of your TELNETSYM queues. For example:

    $ DEFINE /SYSTEM TCPIP$TELNETSYSM_SCRATCH device:[directory.path]

    If you define the logical name TCPIP$TELNETSYM_SCRATCH, the log files are stored in the TCPIP$TELNETSYM_SCRATCH directory.
    If you do not define TCPIP$TELNETSYM_SCRATCH, the log files are stored in TCPIP$LPD_SPOOL.
    If TCPIP$LPD_SPOOL is not defined, the log files go into the SYS$SPECIFIC:[SYSEXE] directory.

23.5.3 Controlling Characteristics of the TCP/IP Link

The TELNETSYM configuration logical names allow you to set TELNETSYM parameters. To see the default values for these parameters, enter the following command:

  Delay ACK:              enabled
  Window scale:           enabled
  Drop count:                   8
  Probe timer:                150

                          Receive                Send

  Push:                  disabled            disabled
  Quota:                    61440               61440

The logicals that you can use to modify these parameters are:

    Controls KEEPALIVE processing.
    The KEEPALIVE timer is used to periodically test the other end of a link that appears to be idle. Its purpose is to detect when a remote host has failed or has been brought down, or when the logical connection has been broken.
    For TELNETSYM, you control this timer with the following command:


    This logical name is not used by the server; it is used by the TELNET client. If you are changing this logical name, then there is no need to restart TCP/IP Services. If this logical is defined, the KEEPALIVE function is enabled.
    By default, the KEEPALIVE timer is disabled. Broken connections will be detected only when the relevant application sends data.
    The DROP timer indicates how long a connection should be maintained (after repeated timeouts) before closing the connection. The DROP timer is in effect only after the link has been established, and it takes effect only if the KEEPALIVE logical is also defined.
    You control the DROP timer using the following command:


    where x specifies the number of seconds to hold the connection before closing it.
    The default value for the DROP timer is 300 seconds.
    Note that the value for the DROP timer must be greater than the value for the PROBE timer. When you define only one of these TELNETSYM logical names, the default value will be used for the other logical name.
    This logical name allows you to control the PROBE timer.
    The PROBE timer defines:
    • When establishing an initial connection, the number of seconds TCP/IP Services will wait for a response before a timeout occurs. You can enable this function even if the KEEPALIVE timer is disabled.
    • The length of time allowed to pass before TCP/IP Services checks an idle connection. This function requires that the KEEPALIVE timer be enabled.

    You control the PROBE timer using the following command:


    In this command, x specifies the number of seconds to wait before timing out the connection.
    The value of the PROBE timer must always be less than or equal to the value of the DROP timer. The default value for the PROBE timer is 75 seconds.
    Specifies the size of the socket send buffer that TELNETSYM uses.

Previous Next Contents Index