If a network link has not been established, the TELNET symbiont attempts to establish one. Printing starts when the link is successfully established. The TELNET symbiont continues to try to establish a network link until it is successful or until a retry interval you define has expired.

The logical name TCPIP$TELNETSYM_RETRY_INTERVAL defines the time for TELNETSYM to wait between link-establishment retries when link establishment has failed. The value for this logical name is an OpenVMS delta time.

If this logical name is not defined, TELNETSYM defaults to a wait period of 3 minutes between retries.

For example, to define a retry interval of 30 seconds, enter:

$ DEFINE /SYSTEM TCPIP$TELNETSYM_RETRY_INTERVAL "0 00:00:30.00"

23.5.5 Releasing a TELNETSYM Link

By default, TELNETSYM releases an established link at the end of a print job. This behavior is useful when multiple systems contend for the same printer. Configuring TELNETSYM to release the link at the end of a job allows other systems to print quickly. However, this behavior can also be a disadvantage because of the overhead involved with link creation for each print job.

When there is little or no contention for a printer, it is useful to configure TELNETSYM to release the link only after a certain period of idle time has passed. With this approach, TELNETSYM waits for the configured idle time to elapse and then closes the link. This option works well within batch printing applications.

Use the logical name TCPIP$TELNETSYM_IDLE_TIMEOUT to define the length of time to wait before terminating an inactive link. Specify a value that is an OpenVMS delta time.

For example, to define a link-idle-timeout of 10 minutes, enter:

$ DEFINE /SYSTEM TCPIP$TELNETSYM_IDLE_TIMEOUT "0 00:10:00.00"

Idle time occurs during printing as well as between print jobs. Any idle time on the link can cause a timeout. Therefore, it is important to adjust the value of this logical carefully.

23.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 16) when defining this logical name is passed to the PSM$PRINT system routine. The default is a maximum of 16 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.

23.6 Solving TELNETSYM Problems

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

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

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

If TELNETSYM causes a print queue to fail, reset the queue. Enter the following command:

$ STOP /QUEUE /RESET queue-name

23.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 Compaq 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 23.1.1.
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_FORM FEEDS 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 following bit settings:

   63 <----- unused -----> 6|54|32|1|0 _____________________________________ | XXXXXXXXXXXXXXXXXXXXXXXX|ll|XX|s|c| ------------------------------------- 10 00 1 1 --->---> binary 100011 ^^ ^ ^ | | | 10 is binary for decimal ----+ +-+--<-- set both the setup and comp. bits 2 is level 2

   
   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_FORM FEEDS 35

2. This example shows how to determine the value of the TCPIP$TELNETSYM_SUPPRESS_FORM FEEDS 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:

   63 <----- unused -----> 6|54|32|1|0 _____________________________________ | XXXXXXXXXXXXXXXXXXXXXXXX|ll|XX|s|c| ------------------------------------- 01 00 0 1 --->---> binary 010001 ^^ ^ ^ | | | 01 is binary for decimal ----+ +-+--<-- set only the comp. bit 1 is level 1

   
   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_FORM FEEDS 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 24.1)
• How to provide PC-NFS printing services ( Section 24.2)
• How to manage PC-NFS print queues ( Section 24.3)
• PC-NFS authentication ( Section 24.4)

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

24.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.
• Appendix D, Acronyms, contains a list of acronyms for OpenVMS and networking.

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