Compaq TCP/IP Services for OpenVMS
Management


Previous Contents Index

23.5.4 Establishing a TELNETSYM Link

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:

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

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.

23.6.4.1 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_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 
    

23.6.4.2 Buffer Dumps

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 


Chapter 24
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 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:

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

24.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:


    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.

24.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:

24.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
Appendixes

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

Note

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

Note

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.


Previous Next Contents Index