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:

/PROCESSOR=TELNETSYM

to:

/PROCESSOR=TCPIP$TELNETSYM

25.6.2 Printing to Terminal Servers

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

• Input flow control is disabled for the port to which you are printing.
  Enter:

  > CHANGE PORT port INPUT FLOW DISABLED

• The TELNET server for the terminal server port is set to recognize a new line as a carriage-return character followed by a line feed character.
  Enter:

  > CHANGE PORT port TELNET SERVER NEWLINE TO HOST

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:

   $ DEFINE /SYSTEM TCPIP$TELNETSYM_DEBUG 4 $ STOP /QUEUE /RESET TELNETSYM_queue-name $ 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.

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:

• Bits 0 and 1 specify when to do form feed suppression. It can be done at either job setup or job completion time, or both. At least one of these bits must be set to enable form feed suppression.
• Bits 4 and 5 together specify how to perform form feed suppression. With TCP/IP Services, you can set either of two levels of form feed suppression. Both levels eliminate the form feed character from the stream of output bytes that is sent when the queue is first started.
  • Level 1 form feed suppression operates similarly to form feed suppression under previous versions of TCP/IP Services. It will not eliminate subsequent form feed characters, but will instead substitute a line feed character for the form feed character. As a result, what would have been a carriage-return/form feed sequence in the output stream becomes a carriage-return/linefeed sequence.
  • Level 2 form feed suppression eliminates all form feed characters and carriage-return/form feed sequences from the output stream.

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.

   Figure 25-1 TCPIP$TELNETSYM_SUPPRESS_FORMFEEDS Level 2 Setting

   ---

   
   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:

   $ DEFINE/SYSTEM TCPIP$TELNETSYM_SUPPRESS_FORMFEEDS 35

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.

   Figure 25-2 TCPIP$TELNETSYM_SUPPRESS_FORMFEEDS Level 1 Setting

   ---

   
   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:

   $ DEFINE/SYSTEM TCPIP$TELNETSYM_SUPPRESS_FORMFEEDS 17

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 Tab 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:

\FF\FD\00\FF\FB\00

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:

• How to start up and shut down the PC-NFS server ( Section 26.1)
• How to provide PC-NFS printing services ( Section 26.2)
• How to manage PC-NFS print queues ( Section 26.3)
• PC-NFS authentication ( Section 26.4)

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:

• SYS$STARTUP:TCPIP$PCNFS_STARTUP.COM allows you to start up the PC-NFS server independently.
• SYS$STARTUP:TCPIP$PCNFS_SHUTDOWN.COM allows you to shut down the PC-NFS server 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$PCNFS_SYSTARTUP.COM can be used as a repository for site-specific definitions and parameters to be invoked when the PC-NFS server is started.
• SYS$STARTUP:TCPIP$PCNFS_SYSHUTDOWN.COM can be used as a repository for site-specific definitions and parameters to be invoked when the PC-NFS server is shut down.

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:

   TCPIP> MAP "/PC_PRINT/WORK" DSA31:

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

   TCPIP> ADD EXPORT "/PC_PRINT/WORK" /HOST=* /OPTIONS=TYPELESS_DIRECTORIES

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

   DEFINE /SYSTEM TCPIP$PCNFSD_SPOOLDEV DSA31: DEFINE /SYSTEM TCPIP$PCNFSD_SPOOLEXPORT "/PC_PRINT/WORK"

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

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:

• List jobs queued from the PC
• Cancel queued jobs
• Obtain a list of available print queues
• Obtain status of a particular print queue

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 contains the following appendixes:

• Appendix A, Gateway Routing Daemon (GATED) Configuration Reference, describes how to configure GATED protocols for use with the Gateway Routing Daemon (GATED).
• Appendix B, EBCDIC/DMCS Translation Tables, provides EBCDIC/DMCS translation tables.
• Appendix C, How NFS Converts File Names, describes how NFS converts UNIX file names to OpenVMS file names.

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.)

• A pound sign (#)
• The C-style comments that start with /* and end with */

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

The following statements do not fit in the above categories:

• %directive statements
• %trace statements

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 { broadcast; interface all ripin ripout version 1; }; redirect on; routerdiscovery server off; hello off; ospf off; egp off; bgp off; snmp off; # # Static routes: # #static { # 10.1.2.0 mask 255.255.255.0 gateway 10.1.1.1; # default gateway 10.1.2.3; # }; # # 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:

• May appear in several different configuration statements in the configuration file. Be aware, however, that the last, or most specific value set for a route is the value GATED will use.
• May specify one network interface over another, one protocol over another, or one remote gateway over another.
• Cannot be used to control the selection of routes within an interior gateway protocol (IGP). That function is accomplished automatically by the protocol based on metric.
• May select routes from the same exterior gateway protocol (EGP) learned from different peers or autonomous systems.

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

• The route with the best (numerically smallest) preference is selected.
• If the two routes have the same preference, the route with the best (numerically smallest) preference2 is selected.
• A route from an IGP is selected over a route from an EGP. The least preferred is a route learned indirectly by an IGP from an EGP.
• If autonomous system (AS) path information is available, it is used to help determine the most preferred route as follows:
  • A route with an AS path is selected over one without an AS path.
  • If the AS paths and origins are identical, the route with the lower metric is selected.
  • A route with an AS path origin of IGP is preferred over a route with an AS path origin of EGP. The least preferred is an AS path with an unknown origin.
  • A route with a shorter AS path is preferred.
  • If both routes are from the same protocol and AS, the one with the lowest metric is selected.
  • The route with the lowest numeric next-hop address is used.