# DIGITAL TCP/IP Services for OpenVMS
Management

Previous | Contents

Use the following logical names to modify error logging:

- UCX$TELNETSYM_VERBOSE
  Turns on the logging of TELNETSYM diagnostics to the file UCX$TELNETSYM.LOG. These diagnostics include informational messages that indicate when links have come up or gone down, and error messages.
- UCX$TELNETSYM_NO_OPCOM
  Stops TELNETSYM from sending messages to the operator console.
- UCX$TELNETSYM_DEBUG
  Used with UCX$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 issuing:

      $ DEFINE /SYSTEM UCX$TELNETSYM_DEBUG 4

  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 and, therefore, causes logging of flow of code and memory allocation diagnostics.
  If UCX$TELNETSYM_DEBUG is undefined, TELNETSYM does not log these diagnostics.
  Bit 2 is useful in unassisted problem solving. Bits 0 and 1 are primarily for DIGITAL use. However, with knowledge of PSM$ symbionts, you might find all the options useful.
- UCX$TELNETSYM_LOG_KEEP
  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:

      $ DEFINE /SYSTEM UCX$TELNETSYM_LOG_KEEP 3

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

      $ DEFINE UCX$TELNETSYSM_SCRATCH device:[directory.path]

## 17.4.3 Controlling Characteristics of the TCP/IP Link

TELNETSYM configuration logical names in this category correspond directly to item list options for the UCX $QIO SETMODE function. Issue UCX SHOW PROTOCOL TCP /PARAMETER to see the default values for these SETMODE options.

- UCX$TELNETSYM_DROPTIME
  If defined, this logical name uses the value set with the $QIO SETMODE option UCX$C_TCP_DROP_IDLE.
  Note that the value for drop time must be greater than the value for probe time. When you define only one of these TELNETSYM logical names, the default value will be used for the other logical name.
- UCX$TELNETSYM_KEEPALIVE
  Turns on the the $QIO SETMODE UCX$C_KEEPALIVE option.
- UCX$TELNETSYM_PROBETIME
  If defined, this logical name uses the value set with the $QIO SETMODE option UCX$C_TCP_PROBE_IDLE.
- UCX$TELNETSYM_SNDBUF
  If defined, this logical name uses the value set with the $QIO SETMODE option UCX$C_SO_SNDBUF.

## 17.4.4 Establishing a TELNETSYM Link

If a network link is unavailable, the TELNET symbiont attempts to open 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 UCX$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, issue:

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

## 17.4.5 Releasing a TELNETSYM Link

By default, TELNETSYM releases an open 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 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 UCX$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, issue:

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

## 17.4.6 Setting the Number of Execution Queues

The logical name UCX$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.

An important use of this logical is to turn TELNETSYM into a single-threaded symbiont (value=1) where each queue runs its own process. This makes diagnosing problems easier and lessens the consequences of a crash.

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

# Chapter 18
Setting Up the PC-NFS Print Service

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 set up printing for PC-NFS client users. If you need help setting up NFS proxy identities for PC-NFS client users and starting the PC-NFS server, see Chapter 14 in this manual for more information.

# 18.1 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 pathname. For example,

       UCX> MAP "/PC_PRINT"  DSA31:

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

       UCX> ADD EXPORT
       "/PC_PRINT/directory/subdirectory" /HOST=* /OPTIONS=TYPELESS DIRECTORIES

4. Add the following logical names to the file SYS$STARTUP:UCX$NFS_SERVER_STARTUP.COM:

       DEFINE /SYSTEM UCX$PCNFSD_SPOOLDEV device:)

       DEFINE /SYSTEM UCX$PCNFSD_SPOOLEXPORT "/path/name"

# 18.2 Maintaining 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, log into either a privileged account or the PC's proxy account on the NFS server host and issue 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

# 18.3 Authentication

When accessing files on an NFS server, a PC user obtains authentication once from any host running PC-NFS and can access NFS files on that host or other hosts, even though the user's UID/GID may have proxy mappings to a different OpenVMS account on each UCX host.

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

# Part 6
Appendixes

Part 6 contains six appendixes.

Appendix A explains how to identify and resolve problems with UCX software.

Appendix B describes the error and informational messages you may receive when using UCX software.

Appendix C describes the error messages you may receive when analyzing NFS UNIX-style and OpenVMS-style file systems.

Appendix D provides a template for creating a customized security driver.

Appendix E provides EBCDIC/DMCS translation tables.

Appendix F describes how NFS converts UNIX file name to OpenVMS files names.

# Appendix A
Troubleshooting

This appendix provides troubleshooting tools and techniques you can use to identify and correct problems with the DIGITAL TCP/IP Services for OpenVMS software.

This appendix provides information on

- Using TCPIPTRACE (Section A.1)
- Tuning performance (Section A.2)
- General problems, for example, user problems with accessing a service (Section A.3)
- BIND Server load balancing (Section A.4)
- BOOTP (Section A.5)
- TFTP (Section A.6)
- FTP (Section A.7)
- Printing: LPD (Section A.8)
- Printing: TELNETSYM (Section A.9)
- SLIP (Section A.10)
- SMTP (Section A.11)
- TELNET (Section A.13)

# A.1 Using the Trace Utility (TCPIPTRACE)

DIGITAL TCP/IP Services for OpenVMS provides a troubleshooting tool you can use to trace packets going in and out of the system. To run the trace utility, issue the DCL command TCPIPTRACE. Use the qualifiers listed in Table A-1 to customize tracing for your particular problem.

Part of a TCPIPTRACE display looks like the following example.

        UCX INTERnet trace RCV packet seq # = 1 at 23-OCT-1997 15:19:33.29

       IP Version = 4,  IHL = 5,  TOS = 00,   Total Length = 217 = ^x00D9
       IP Identifier  = ^x0065,  Flags (0=0,DF=0,MF=0),
             Fragment Offset = 0 = ^x0000,   Calculated Offset = 0 = ^x0000
       IP TTL = 32 = ^x20,  Protocol = 17 = ^x11,  Header Checksum = ^x8F6C
       IP Source Address      = 16.20.168.93
       IP Destination Address = 16.20.255.255

       UDP Source Port = 138,   UDP Destination Port = 138
       UDP Header and Datagram Length = 197 = ^x00C5,   Checksum = ^x0E77

       5DA81410   8F6C1120   00000065   D9000045    0000    E...awe.....l....]
                | 0E77C500   8A008A00 | FFFF1410    0010    ..........w.

Table A-1 TCPIPTRACE Command Qualifiers
Qualifier | Function
--- | ---
/BUFFERS= n | Optional. Default: 100. Number of buffers that UCX$TRACE allocates for temporary storage. These buffers must be locked into the working set, so the number can be: Decreased to be accommodated in the working set Raised to prevent the dropping of trace packets
/FULL | Optional. Default: brief display. Displays the packet's contents.
/OUTPUT= file | Optional. Default: Screen display. Redirects the output from screen to the specified file. If this file name already exists, the output is appended to it.
/PACKETS= n | Optional. Default: 10. Stops the trace after the specified number of packets is displayed.
/PORT= LOCAL REMOTE = n | Optional for port number. Default: all traffic is displayed. Required for port type. Filters the trace to the specified port.
/PROTOCOL= ARP ICMP IP TCP UDP | Optional. Default: /PROTOCOL=IP. Filters on the specified protocol.

Examples:

    $ TCPIPTRACE HOST1 /FULL /PORT=REMOTE=21

    $ TCPIPTRACE HOST2 /PORT=(LOCAL=23, REMOTE=1056) -
    _$ /FULL /PACKETS=30 /OUTPUT=TELNET_TRACE.TXT

# A.2 Tuning Performance

To tune settings for better performance, use the following commands:

- STOP ROUTING
- SET COMMUNICATION
- SHOW COMMUNICATION
- SET CONFIGURATION COMMUNICATION
- SHOW CONFIGURATION COMMUNICATION
- SET PROTOCOL
- SHOW PROTOCOL
- SET CONFIGURATION PROTOCOL
- SHOW CONFIGURATION PROTOCOL
- START ROUTING

## A.2.1 Permanent Settings

The SET COMMUNICATION and SET PROTOCOL commands are interactive. The next time UCX starts up, your changes are overwritten if they differ from the permanent database's settings.

The SET CONFIGURATION PROTOCOL and SET CONFIGURATION COMMUNICATION commands modify the permanent configuration database. They do not take effect until the next UCX startup, but they are "restored" upon re-boot.

To both immediately and permanently modify settings, issue both the interactive command and the matching SET CONFIGURATION command.

## A.2.2 Isolating the Problem

If you experience slow performance, try to isolate the problem with the following steps:

1. Monitor the use of the internet memory buffers (MBUFs). Issue these commands:
   - SHOW COMMUNICATION /MEMORY
   - SHOW COMMUNICATION /CONTINUOUS
2. Check the Drops and Waits counters for the UCX buffers, which are:
   - Small buffers
   - Large buffers
   - I/O request packets (IRPs)
   If these counters are rapidly going up, increase the maximum values of the following qualifiers (take into account that the allocation of these buffers affects the available nonpaged pool):
   - /SMALL_BUFFERS=n
     This value affects the number of buffers in control clusters.
   - /LARGE BUFFERS=n
     This value affects the number of buffers in data clusters.
   Issue the following commands:

       UCX> SET COMMUNICATION /SMALL_BUFFERS=n /LARGE_BUFFERS=n

       UCX> SET CONFIGURATION COMMUNICATION -
       _UCX> /SMALL_BUFFERS=n /LARGE_BUFFERS=n

   Monitor the User Buffer Unavailable counter for the communication controller, for example, Ethernet, FDDI, or Token Ring. Issue:

       NCP> SHOW KNOWN LINES COUNTERS

   If the display does not provide sufficient information, determine which user is having a problem with the DCL commands ANALYZE /SYSTEM or ANALYZE /CRASH. Issue:

       $ ANALYZE/SYSTEM
       ANALYZE>  SHOW DECNET /DATALINK

   Note the data for:
   - Ethernet Protocol 08-00 (IP)
   - Ethernet Protocol 08-06 (ARP)
3. Examine again the User Buffer Unavailable counter. If it is too high compared to the number of received datagrams for IP, increase the number of UCX receive buffers. Missed datagrams are unrelated to:
   - Drops reported by SHOW INTERFACE, which show how many of the buffer or IRP drops are associated with a specific interface.
   - Error counters displayed with SHOW INTERFACE, which show errors detected only on received and transmitted datagrams.
4. Shut down UCX.
5. Start the communication software. Issue one of these commands:
   - START COMMUNICATION (uses dynamic information on the running system)
   - START COMMUNICATION /INITIALIZE (uses information stored in the configuration database)
6. If the new values improve performance, make the changes permanent. Issue:
   - SET CONFIGURATION COMMUNICATION
   - SET CONFIGURATION PROTOCOL

   ## A.2.3 Buffer Usage

   To monitor buffer usage, issue these commands:

       $ UCX SHOW COMMUNICATION /MEMORY

       $ SHOW MEMORY /FULL

   Example 1:
   In this display, the Peak counter shows the demand on small and large buffers. (UCX rounds up or down the number of MBUFs. Therefore, the numbers in the display might differ from the numbers you specified.)

       UCX> SHOW COMMUNICATION /MEMORY
                                      MBUF Summary
                         Small_static  Large_static  Small_dynamic  Large_dynamic
       Total buffers              30            10            30              0
       Free                       1             9             28              0
       Busy
        Data                      0             1              0              0
        Header                    0             0              0              0
        Socket                    7             0              2              0
        Prot. control             5             0              0              0
        Route                    15             0              0              0
        Socket name               0             0              0              0
        Socket options            0             0              0              0
        Fragment reassembly       0             0              0              0
        IP address                2             0              0              0
       Size of cluster         7936         16896           7936              0

                    Free       Current          Peak          Waits        Drops
       Small Buffers              31            36              0              0
       Large Buffers               1            12              0              0
       IRPs         12             3            14              0              0

                      Small clusters  Large clusters    Non UCX buffers
       Free                        0             1              7

   SHOW MEMORY /FULL displays the value for free nonpaged dynamic memory. You can use this value to optimize the number of available dynamic MBUFs.

   Example 2:
   The following display shows that, of the physical pages in use, 50948 pages are permanently allocated to OpenVMS.

       $ SHOW MEMORY /FULL

                     System Memory Resources on  24-NOV-1997 10:33:05.05

       Physical Memory Usage (pages):     Total        Free      In Use    Modified
         Main Memory (128.00Mb)          262144      117187      135335    9622

       Slot Usage (slots):                Total        Free    Resident    Swapped
         Process Entry Slots                200         106          94    0
         Balance Set Slots                  180          88          92    0

       Fixed-Size Pool Areas (packets):   Total        Free      In Use    Size
         Small Packet (SRP) List           7820        1112        6708    128
         I/O Request Packet (IRP) List     7997        2121        5876    176
         Large Packet (LRP) List           1456        1268         188    1856

       Dynamic Memory Usage (bytes):      Total        Free      In Use    Largest
         Nonpaged Dynamic Memory        9151488     6904880     2246608    6726608
         Paged Dynamic Memory           4319232     2570784     1748448    2556720

       Paging File Usage (pages):                      Free  Reservable    Total
         DISK$UCXDEV_LAVC:[SYS0.SYSEXE]PAGEFILE.SYS
                                                      30384      -24981    33296
         WORK4$:[SYS0.SYSEXE]PAGEFILE1.SYS;1          84168      -74323    99992

       Of the physical pages in use, 50948 pages are permanently allocated to VMS.

   ### A.2.3.1 Nonpaged Pool

   UCX stores user data in the OpenVMS system space (nonpaged pool). Buffer space and quotas have these effects:

   - Receive buffer quota --- When UCX's receive buffer quota is reached, UCX discards the messages received for a device socket (see Section A.2.4).
   - Send buffer quota --- If the send buffer quota is reached, UCX puts the process in a resource WAIT. A process using NOWAIT, for example, a DISMOUNT /NOWAIT command, receives an I/O error on a write request that exceeds the send buffer quota.
   - Socket buffer size quotas impact performance.

   Improve performance by modifying UCX's use of nonpaged pool device sockets. Change, as needed, the quotas for the send socket buffers and receive socket buffers.

   To determine the quota for a device socket, specify a socket buffer size quota for the transmit and receive operations of UDP and TCP. Issue:

       UCX> SET PROTOCOL TCP /QUOTA=(RECEIVE:n,SEND:n)

   or

       UCX> SET CONFIGURATION PROTOCOL TCP /QUOTA=(RECEIVE:n,SEND:n)

   Table A-2 lists the default and maximum bytes for these quotas.

   Table A-2 Queue Size Quotas for Device Sockets
   Operation | Default | Maximum
   --- | --- | ---
   Hosts with Ethernet-sized buffers
   UDP/IP Receive | 9000 bytes | 128K bytes
   UDP/IP Transmit | 9000 bytes | 128K bytes
   TCP/IP Receive | 4096 bytes | 512K bytes
   TCP/IP Transmit | 4096 bytes | 512K bytes
   RAW_IP Receive | 2048 bytes | 64K bytes
   RAW_IP Transmit | 2048 bytes | 64K bytes
   Hosts with FDDI-sized buffers
   UDP/IP Receive | 72K bytes | 128K bytes
   UDP/IP Transmit | 72K bytes | 128K bytes
   TCP/IP Receive | 8192 bytes | 512K bytes
   TCP/IP Transmit | 8192 bytes | 512K bytes
   RAW_IP Receive | 2048 bytes | 64K bytes
   RAW_IP Transmit | 2048 bytes | 64K bytes

   Example:
   The following commands specify a receive socket buffer quota of 8600 and a transmit socket buffer quota of 9700.

       UCX> SET PROTOCOL TCP /QUOTA=(RECEIVE:8600,SEND:9700)
       UCX> SHOW PROTOCOL TCP /PARAMETERS

       TCP
         MTU size segment:      disabled
         Delay ACK:              enabled
         Loopback:              disabled
         Window scale:           enabled
         Drop timer:                 600
         Probe timer:                 75

                                 Receive                Send

         Checksum:               enabled             enabled
         Push:                  disabled            disabled
         Quota:                     8600                9700

       UCX> SET CONFIGURATION PROTOCOL TCP /QUOTA=(RECEIVE:8600,SEND:9700)
       UCX> SHOW CONFIGURATION PROTOCOL TCP

       TCP
         MTU size segment:      disabled
         Delay ACK:              enabled
         Loopback:              disabled
         Window scale:           enabled
         Drop timer:                   0
         Probe timer:                  0

                                 Receive                Send

         Checksum:               enabled             enabled
         Push:                  disabled            disabled
         Quota:                     8600                9700

   The amount of required nonpaged pool space depends on your network configuration. UCX uses the following buffer space allocated from the OpenVMS nonpaged pool:

   - Buffers specific to OpenVMS (internet I/O request packets [IRPs] and large request packets [LRPs])
   - Buffers for the internet memory buffers (MBUFs) and device sockets (see Table A-3)

   Table A-3 Default Buffer Sizes
   Default MBUFs Used by UCX | Number of Bytes
   --- | ---
   Small buffers | 256
   Large buffers for Ethernet-only hosts | 1792
   Large buffers for FDDI hosts | About 4500

   ### A.2.3.2 Setting Optimal Large Buffer Sizes

   For maximum performance of FDDI, UCX automatically selects the larger buffers when you configure at least one FDDI interface.

   To override this default, issue the following command. The change takes effect upon the next UCX startup.

       UCX> SET CONFIGURATION COMMUNICATION /TYPE=interface_type

   where:

   - /TYPE=DEFAULT --- automatically generates 4500-byte large buffers, if at least one active FDDI interface exists. If not, the type is set to ETHERNET.
   - /TYPE=ETHERNET --- invokes large buffers of about 1500 bytes
   - /TYPE=FDDI --- invokes large buffers of about 4500 bytes

   ### A.2.3.3 Preallocated MBUFs

   UCX preallocates MBUFs in blocks called control clusters and data clusters, as follows:

   - Control clusters consist of small MBUFs that store information related to:
     - Device sockets
     - Internal control structures
     - IP addresses
     - IP routes
     - IP packet headers
   - Data clusters consist of large MBUFs that buffer the data in the system space as follows:
     - Before actual transmission, a transmit data operation moves data from the user process space to the large buffer.
     - Until a user process is ready to read data, a receive data operation stores received data in the large buffers.

   The UCX startup procedure allocates a specific number of the MBUF control clusters and data clusters from the OpenVMS nonpaged pool. To change the defaults, issue the SET COMMUNICATION or SET CONFIGURATION COMMUNICATION command with the qualifiers shown in Table A-4.

   Table A-4 Modifying MBUF Allocation
   Modification | Qualifier | Default
   --- | --- | ---
   Control clusters | /SMALL_BUFFERS=MIN= n | 50
   | /SMALL_BUFFERS=MAX= n | 1000
   Data clusters | /LARGE_BUFFERS=MIN= n | 10
   | /LARGE_BUFFERS=MAX= n | 200

   Previous | Next | Contents