Use the following logical names to modify error logging:
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. |
$ DEFINE /SYSTEM UCX$TELNETSYM_DEBUG 4
$ DEFINE /SYSTEM UCX$TELNETSYM_LOG_KEEP 3
$ DEFINE UCX$TELNETSYSM_SCRATCH device:[directory.path]
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.
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"
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"
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.
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:
UCX> MAP "/PC_PRINT" DSA31:
UCX> ADD EXPORT "/PC_PRINT/directory/subdirectory" /HOST=* /OPTIONS=TYPELESS DIRECTORIES
DEFINE /SYSTEM UCX$PCNFSD_SPOOLDEV device:) DEFINE /SYSTEM UCX$PCNFSD_SPOOLEXPORT "/path/name"
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
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 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.
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
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.
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:
|
/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=
|
Optional for port number. Default: all traffic is displayed. Required for port type. Filters the trace to the specified port. |
/PROTOCOL=
|
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
To tune settings for better performance, use the following commands:
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:
UCX> SET COMMUNICATION /SMALL_BUFFERS=n /LARGE_BUFFERS=n UCX> SET CONFIGURATION COMMUNICATION - _UCX> /SMALL_BUFFERS=n /LARGE_BUFFERS=n
NCP> SHOW KNOWN LINES COUNTERS
$ ANALYZE/SYSTEM ANALYZE> SHOW DECNET /DATALINK
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.
UCX stores user data in the OpenVMS system space (nonpaged pool). Buffer space and quotas have these effects:
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.
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:
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 |
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:
UCX preallocates MBUFs in blocks called control clusters and data clusters, as follows:
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.
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 |