HP TCP/IP Services for OpenVMS

Previous Contents Index

25.5.6 Setting the Number of Execution Queues

The logical name TCPIP$TELNETSYM_STREAMS defines the number of execution queues handled by each TELNETSYM process. The value you enter (a number from 1 through 32) when defining this logical name is passed to the PSM$PRINT system routine. The default is a maximum of 32 queues per symbiont process.

Use this logical to turn TELNETSYM into a single-threaded symbiont (value=1) in which each queue runs its own process. This makes diagnosing problems easier and lessens the consequences of a failure.

If you are defining this logical name, define it once. Do not define it differently for each TELNETSYM print queue.

25.6 Solving TELNETSYM Problems

To avoid potential problems with TELNET printing, be aware of the following guidelines and considerations.

25.6.1 Using TCPIP$TELNETSYM for the First Time

If you use the public domain TELNET symbiont and want to switch to the TCP/IP Services TELNET symbiont, you must change the value of the /PROCESSOR qualifier on the TELNET symbiont queues. When you do this, include any command procedures that start up the queues. Change:




25.6.2 Printing to Terminal Servers

When you print to a terminal server system, ensure that:

25.6.3 Stalled Print Queues

When you print a job to a TELNETSYM queue, a link must be established between the queue and the printer. If there is high contention for the printer, it might be busy, causing the first attempt to fail.

TELNETSYM continues to try to establish the link, according to the retry interval logical name TCPIP$TELNETSYM_RETRY_INTERVAL. Until the link is established, the execution queue stalls. When the link comes up, the job prints. A stalled TELNETSYM queue is not necessarily an error.

If the queue stalls while printing a job, the printer probably requires human intervention; that is, the printer is out of paper or jammed.

25.6.4 Solving Formatting Problems

To track down problems with improper formatting on the printed page (for example, "garbage" for a graphics file or unwanted blank pages), use bit 2 of the TELNETSYM logical name TCPIP$TELNETSYM_DEBUG. Defining this logical helps determine whether the source of the problem is TELNETSYM. Follow these steps:

  1. Define the logical as 4 in the system table. Enter:

    $ START /QUEUE TELNETSYM_queue-name

  2. Print the job that does not print properly.
  3. Look at the TELNETSYM log file for the queue.
    This file has messages that show you every byte sent over the link to the printer, such as control characters and setup/reset modules.
    If the raw TCP logical name is not defined, you will see doubled IAC characters (hexadecimal FF).
    If you print /PASSALL with the raw TCP logical name not defined, the job starts with the TELNET options negotiation sequence "do binary, will binary."
  4. Identify the problem. Either fix it or report it to your HP support representative. Keep in mind that the OpenVMS print symbiont may be the cause of the problem. TELNETSYM only modifies the output as described in Section 25.1.2.
  5. Turn off debug mode.
  6. Start the TELNETSYM queue. Controlling Form Feed Suppression

Use the TCPIP$TELNETSYM_SUPPRESS_FORMFEEDS logical to control the suppression of form feeds. The bit settings you specify in the value control the time of the operation and the type of form feed suppression to perform:

The following examples show how to calculate the value for the logical name:

  1. This example shows how to determine the value of the TCPIP$TELNETSYM_SUPPRESS_FORMFEEDS logical if you want level 2 form feed suppression at both job setup and job completion times. The value of the logical is determined by the bit settings shown in Figure 25-1.


    The binary value for level 2 form feed suppression at both job setup and job completion time is 100011 (hexadecimal 23 or decimal 35). Because the value of the logical is a decimal value, you define it as follows:


  2. This example shows how to determine the value of the TCPIP$TELNETSYM_SUPPRESS_FORMFEEDS logical if you want level 1 form feed suppression at job completion time only. The value of the logical is determined by the following bit settings shown in Figure 25-2.


    The binary value for level 1 form feed suppression at job completion time only is 010001 (hexadecimal 11 or decimal 17). Because the value of the logical is a decimal value, you define it as follows:


TELNETSYM logs control characters and nonprinting characters by preceding the hexadecimal value of the byte with a backslash. For example, the following sequence:

Carriage Control 
Form Feed 
Carriage Control 
Line Feed 
the text "Use Your Screen Saver to Conserve Energy." 
Carriage Return 
Line Feed 

is logged as:

\0D\0C\0D\0A\09Use Your Screen Saver to Conserve Energy.\0D\0A 

The "do binary, will binary" sequence starting off a /PASSALL job appears as:


Chapter 26
Setting Up PC-NFS

The PC-NFS server provides authentication and print services for personal computers running PC-NFS. Users on a PC client can associate the name of the PC printer with an OpenVMS print queue and print files to the associated queue. To access the PC-NFS server, PC users must have an entry in the proxy database and have corresponding OpenVMS accounts on the server.

This chapter describes:

For information about setting up NFS proxy identities for PC-NFS client users, see Chapter 22.

26.1 PC-NFS Startup and Shutdown

The PC-NFS server can be shut down and started up 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:

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

26.2 Providing PC-NFS Print Services

To configure PC-NFS print services, you must create and export a spool directory and define two system logical names. Follow these steps when configuring your print server for printing by PC-NFS clients:

  1. If one does not already exist, create a spool directory.
  2. Map the OpenVMS device to the spool directory path name. For example:


  3. Make the path available with the ADD EXPORT command as follows:


  4. Create or edit the SYS$STARTUP:TCPIP$PCNFS_SYSTARTUP.COM file to include the following logical name definitions:


    The logical name TCPIP$PCNFSD_SPOOLDEV specifies the device name for the spool device; TCPIP$PCNFSD_SPOOLEXPORT specifies the exported spool directory.

26.3 Managing PC-NFS Print Queues

PC users can associate the name of the DOS printer you are configuring with an OpenVMS print queue and print files to the associated queue. PC clients cannot, however, manage NFS print queues from their PC. To manage print queues, you must log in to either a privileged account or the PC's proxy account on the NFS server host, and enter DCL commands to:

26.4 PC-NFS Authentication

When accessing files on an NFS server, a PC user obtains authentication once from any host running PC-NFS. The user can also access NFS files on that host or other hosts, even if the user's UID/GID has proxy mappings to a different OpenVMS account on each TCP/IP host.

However, with PC-NFS printing, if the PC user obtains authentication from one host, the user can only print successfully on other TCP/IP Services hosts that have a valid OpenVMS account for the same user name.

Part 7

Part 7 contains the following appendixes:

Appendix A
Gateway Routing Daemon (GATED) Configuration Reference

This appendix describes how to configure the Gateway Routing Daemon (GATED).

A.1 The GATED Configuration File

You must configure the GATED protocols before starting GATED routing by editing the configuration file TCPIP$GATED.CONF, located in SYS$SYSDEVICE:[TCPIP$GATED]. A template file TCPIP$GATED.TEMPLATE is also available in this directory.

The file TCPIP$GATED.CONF contains statements that select routing protocols, manage routing information, manage independent system routing and control tracing options.

After editing the configuration, enter the TCP/IP management command TCPIP START ROUTING/GATED to start the GATED process. If the configuration file is not formatted correctly, GATED will not be able to parse the file and GATED will terminate.

If you make changes to the GATED configuration file after the GATED process is already running, you must stop GATED by entering the command TCPIP STOP ROUTING/GATED. Then restart the GATED process to make the changes take affect.

See HP TCP/IP Services for OpenVMS Management Command Reference for detailed descriptions of the SET GATED and START ROUTING/GATED commands.

A.2 Configuration File Statement Syntax

Parameters shown in brackets ([]) show optional keywords and parameters. The vertical bar (|) indicates a choice of optional parameters. Parentheses (()) group keywords and parameters, when necessary. For example:

[backbone | (area area)] 

In this example, the brackets indicate that either parameter is optional. The keywords are backbone and area . The vertical bar indicates that either backbone or area area can be specified. Because area is in italics, it is a parameter that you provide.

The following comment styles are valid in a GATED configuration file. (Comments may appear anywhere in the file.)


In a GATED configuration file, statements end with a semicolon (;). Do not use a semicolon as a comment character in your configuration file. Anything following a semicolon is interpreted as the start of the next statement.

A.3 Statement Grouping

The configuration file consists of statements grouped in the following order:

  1. Options statements
  2. Interface statements
  3. Definition statements
  4. Protocol statements
  5. Static statements
  6. Control statements
  7. Aggregate statements


Entering a statement out of order causes an error when parsing the configuration file.

The following statements do not fit in the above categories:

These statements provide instructions to the parser, and control tracing from the configuration file. They do not control the configuration of any protocol and may occur anywhere in the configuration file.

A.4 Configuration Statements

Table A-1 describes each TCPIP$GATED.CONF configuration statement.

Table A-1 GATED Configuration Statements
Command Type Description
%directory directive Sets the directory for include files.
%include directive Includes a file into TCPIP$GATED.CONF.
traceoptions trace Specifies which events are traced.
options definition Defines GATED options.
interfaces definition Defines GATED interfaces.
autonomoussystem definition Defines the autonomous system (AS) number.
routerid definition Defines the originating router (BGP, OSPF).
martians definition Defines invalid destination addresses.
rip protocol Enables the RIP protocol.
kernel protocol Configures kernel interface options.
ospf protocol Enables the OSPF protocol.
egp protocol Enables the EGP protocol.
bgp protocol Enables the BGP protocol.
redirect protocol Configures the processing of ICMP redirects.
icmp protocol Configures the processing of general ICMP packets.
snmp protocol Enables reporting to SNMP.
static static Defines static routes.
import control Defines which routes to import.
export control Defines which routes to export.
aggregate control Defines which routes to aggregate.
generate control Defines which routes to generate.

A.5 Creating the GATED Configuration File

To create a configuration file for your local host, edit a copy of the sample file TCPIP$GATED.TEMPLATE (located in the SYS$SYSDEVICE:[TCPIP$GATED] directory),then save the file to SYS$SYSDEVICE:TCPIP$GATED.CONF.

The following shows the template configuration file:

# File name:      TCPIP$GATED.CONF 
# Product:        HP TCP/IP Services for OpenVMS 
# Version:        V5.4 
# © Copyright 1976, 2003 Hewlett-Packard Development Company, L.P. 
# GATED server configuration file 
interfaces { 
 interface all passive ; 
# Protocols: 
rip on { 
 interface all ripin ripout version 1; 
redirect on; 
routerdiscovery server off; 
hello off; 
ospf off; 
egp off; 
bgp off; 
snmp off; 
# Static routes: 
#static { 
# mask gateway; 
# default gateway; 
# }; 
# Policy: 
#export proto rip { 
# proto static { all metric 1; }; 
# proto direct { all; }; 
# proto rip { all; }; 
# }; 

A.6 Defining Preferences and Routing

The configuration file can define routes from one protocol or peer to another, assigning each route a value, called a preference.

The preference value determines the order of routes to the same destination in a single routing database. The active route is chosen by the lowest preference value. Some protocols implement a second preference ( preference2 ), sometimes referred to as a "tie breaker."

Preferences have the following characteristics:

The GATED daemon selects a route based on the following preference criteria:

Previous Next Contents Index