HP OpenVMS Systems Documentation
Compaq TCP/IP Services for OpenVMS
For a typical image restore, follow normal OpenVMS procedures.
For a nonimage restore, an additional step is required after the restore. The Files--11 file identifiers are recorded in the container file. These must be updated by the TCP/IP management command ANALYZE CONTAINER /REPAIR.
This extra step is also required for an image restore if the save set
is being restored with the /NOINITIALIZE qualifier to a volume with a
different label or if it is being restored to a bound volume set that
has a member that was added since the time of the image backup.
20.11 Setting Up NFS Security Controls
The NFS server and the OpenVMS operating system provide many levels of security controls you can use to protect your file systems. Section 20.1.3, Section 20.1.4, and Section 20.1.7 describe how the server uses the proxy and export databases to restrict client access, and how to use OpenVMS account privileges and file protections to control access to files and directories.
The NFS server provides additional security controls through the use of the noproxy_enabled attribute. You can set this attribute in the NFS server site-specific startup file SYS$STARTUP:TCPIP$NFS_SERVER_SYSTARTUP.COM.
The server uses this attribute while it is running. If the attribute is
set, a proxy is not required for users attempting to access the NFS
server. For more information about the NFS server attributes, see
20.12 Modifying NFS Server Attributes
You can modify the way the NFS server works by specifying NFS server attributes using the SYSCONFIG command. The characteristics of the NFS server that you can modify include:
To make permanent modifications:
$ SYSCONFIG -r nfs_server tcp_threads=20 udp_threads=40
$ @SYS$STARTUP:TCPIP$NFS_SERVER_SHUTDOWN.COM $ @SYS$STARTUP:TCPIP$NFS_SERVER_STARTUP.COM
Future upgrades or installations will not overwrite the definitions in the TCPIP$NFS_SERVER_SYSTARTUP.COM file.
Modifying NFS server characteristics can affect NFS server performance. Be sure you understand the impact (review Section 20.15) before making any changes.
Table 20-3 describes the NFS server attributes.
Enables the use of the
attributes. If this attribute is not set to 1, proxies are required for
If the value is 0, files owned by a user that is not in the proxy database are assumed to be owned by UID=-2/GID=-2. If the value is 1, files owned by a user not in the proxy database are reported to be owned by the values of the noproxy_uid and noproxy_gid attributes.
|noproxy_uid||Specifies the default UID when a user cannot be translated by the proxy.|
|noproxy_gid||Specifies the default GID when a user cannot be translated by the proxy.|
|tcp_threads||Specifies the number of concurrent TCP threads within the server. A value of zero will disable the TCP protocol.|
|udp_threads||Specifies the number of concurrent UDP threads within the server. This value must not be zero.|
Specifies the number of seconds in the time interval since the last
file access request.
The server keeps an activity timestamp for each opened file to help manage the open file cache. You can also modify this value with the /INACTIVITY qualifier to the SET NFS_SERVER command.
The default setting for this variable is 120, or 2 minutes. Be careful not to set this value to a small interval; this might reduce performance.
The file SYS$STARTUP:TCPIP$NFS_SERVER_STARTUP.COM also defines a set of logical names that set the file system parameters. Table 20-4 describes these logical names.
Defines the minimum size of the free buffer list. When the list is
smaller than the value of this logical name, the file system starts to
reclaim used buffers.
The default is 4 buffers.
The free buffer list needs at least 4 free buffers (not taken by cache). If the actual number of free buffers is less than TCPIP$CFS_CACHE_LOW_LIMIT, the used buffers are returned to the free list until the size of the free list reaches the value of TCPIP$CFS_CACHE_HIGH_LIMIT.
Defines the number of buffers the file system tries to keep in the free
The default is 8 buffers. See TCPIP$CFS_CACHE_LOW_LIMIT.
In a busy server environment, setting this parameter higher is likely to improve performance.
|TCPIP$CFS_CACHE_SIZE||Defines the maximum number of cache buffers to be allocated.|
Defines the optimum size (in bytes) of the data transferred between
server and client on READ and WRITE operations.
The default is 8K bytes (8192 bytes). This value is used in most NFS server implementations.
Sets the SHOW_VERSION logical name ON or OFF. If ON, the NFS server
returns to the client file names with version numbers, even if there is
only one version of the file.
The default is OFF.
|TCPIP$CFS_MODUS_OPERANDI||Defines various operating modes. Use only under the advice of your Compaq support representative.|
Defines the terminal device to which the important error messages are
directed, in addition to the normal error messages that are sent to the
The default is _OPA0:.
TCP/IP Services supports a partial implementation of NFS network locking, which allows users to lock files. The software coordinates locks among remote users and between remote and local users. The file locking features is applicable regardless of whether the OpenVMS Record Management Services (RMS) is used. However, NFS does not coordinate network locking and RMS record locks.
This version of NFS does not support byte-range locking. If a byte-range lock request is received, it is handled as a file lock request.
File locking is implemented using the Network Lock Manager (NLM) (also known remote procedure call, or RPC, lockd ) and the Network Status Monitor (NSM) (also known as RPC statd ). The NLM coordinates locks made by clients. The NSM recovers lock information in case the server or client fails. The NSM uses the NLM to keep the host list when the client or the server fails and reboots, as follows:
The NSM and the NLM are enabled if you select LOCKD/STATD in the TCPIP$CONFIG.COM configuration procedure. As a result, two processes are started when you start TCP/IP Services: TCPIP$LOCKD and TCPIP$STATD. The NLM can be configured with the following optional parameters:
To set these parameters, create or edit the following file:
The file locking services can be shut down and started 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:
This section provides information to help you identify and resolve
problems and tune system performance.
20.15.1 Displaying NFS Server Performance Information
The SHOW NFS_SERVER command displays information about the running NFS server. You can use the information to tune NFS server performance.
You can enter SHOW NFS_SERVER for a specific client or host if it is listed in the proxy database. The counter information can be especially useful in determining the load on your system.
For more information about the SHOW NFS_SERVER command, refer the
Compaq TCP/IP Services for OpenVMS Management Command Reference.
20.15.2 Displaying File System Information
The SHOW CFS command is useful for monitoring the distribution of the
file system services and the consumption of system time by the various
system services. See the Compaq TCP/IP Services for OpenVMS Management Command Reference manual for a detailed
description of the SHOW CFS command.
20.15.3 Increasing the Number of Active Threads
The NFS server is an asynchronous, multithreaded process. This means that multiple NFS requests can be processed concurrently. Each NFS request is referred to as a thread. With increased server activity, client users may experience timeout conditions. Assuming the server host has the available resources (CPU, memory, and disk speed), you can improve server response by increasing the number of active threads. You do this by changing the value for the appropriate NFS server attributes, as described in Section 20.12.
The NFS server supports both TCP and UDP connections. You can control the maximum number of concurrent threads for each type of connection.
Do not set the UDP maximum threads to zero. If you set the variable to zero, the protocol will be disabled.
If you increase the number of active threads, you should also consider increasing the timeout period on UNIX clients. You do this with the /TIMEOUT option to the TCP/IP Services MOUNT command.
If your clients still experience timeout conditions after increasing
the number of active threads and the timout period on the client, you
may need to upgrade your hardware.
20.15.4 OpenVMS SYSGEN Parameters That Impact Performance
The following OpenVMS SYSGEN parameters impact NFS server performance:
The NFS server process is also limited by the FILLM of the TCPIP$NFS account's SYSUAF record. The effective value is the lower of the FILLM and CHANNELCNT values.
The Network File System (NFS) client software enables client users to access file systems made available by an NFS server. These files and directories physically reside on the remote (server) host but appear to the client as if they were on the local system. For example, any files accessed by an OpenVMS client --- even a UNIX file --- appear to be OpenVMS files and have typical OpenVMS file names.
This chapter reviews key concepts and describes:
Because the NFS software was originally developed on and used for UNIX machines, NFS implementations use UNIX file system conventions and characteristics. This means that the rules and conventions that apply to UNIX file types, file names, file ownership, and user identification also apply to NFS.
Because the TCP/IP Services NFS client runs on OpenVMS, the client must accommodate the differences between the two file systems, for example, by converting file names and mapping file ownership information. You must understand these differences to configure NFS properly and to successfully mount file systems from an NFS server.
The following sections serve as a review only. If you are not familiar
with these topics, see the DIGITAL TCP/IP Services for OpenVMS Concepts and Planning guide for a more detailed
discussion of the NFS implementation available with the TCP/IP Services
21.1.1 NFS Clients and Servers
NFS is a client/server environment that allows computers to share disk space and users to work with their files from multiple computers without copying them to the local system. Computers that make files available to remote users are NFS servers. Computers with local users accessing and creating remote files are NFS clients. A computer can be an NFS server or an NFS client, or both a server and a client.
Attaching a remote directory to the local file system is called mounting a directory. A directory cannot be mounted unless it is first exported by an NFS server. The NFS client identifies each file system by the name of its mount point on the server. The mount point is the name of the device or directory at the top of the file system hierarchy. An NFS device is always named DNFSn.
All files below the mount point are available to client users as if they reside on the local system. The NFS client requests file operations by contacting a remote NFS server. The server then performs the requested operation. The NFS client automatically converts all mounted directories and file structures, contents, and names to the format required by OpenVMS. For example, a UNIX file named /usr/webster/.login would appear to an OpenVMS client as DNFS1:[USR.WEBSTER].LOGIN;1
The OpenVMS operating system supports multiple file types and record formats. In contrast, NFS and UNIX systems support only byte-stream files, seen to the OpenVMS client as sequential STREAM_LF files.
This means the client must use special record handling to store and
access non-STREAM_LF files.
The OpenVMS NFS client accomplishes this with attribute description
files (ADFs). These are special companion files the client uses to hold
the attribute information that would otherwise be lost in the
translation to STREAM_LF format. For example, a SET FILE/NOBACKUP
command causes the client to create an ADF, because NFS has no concept
of this OpenVMS attribute.
220.127.116.11 Using Default ADFs
The client provides default ADFs for files with the following extensions: .EXE, .HLB, .MLB, .OBJ, .OLB, .STB, and .TLB. (The client does not provide ADFs for files with the .TXT and .C extensions, because these are STREAM_LF.) The client maintains these ADFs on the server.
For example, SYS$SYSTEM:TCPIP$EXE.ADF is the default ADF for all .EXE
type files. When you create .EXE files (or if they exist on the
server), they are defined with the record attributes from the single
default ADF file. The client refers only to the record attributes and
file characteristics fields in the default ADF.
18.104.22.168 How the Client Uses ADFs
By default, the client uses ADFs if they exist on the server. The client updates existing ADFs or creates them as needed for new files. If you create a non-STREAM_LF OpenVMS file or a file with access control lists (ACLs) associated with it on the NFS server, the NFS client checks to see whether a default ADF can be applied. If not, the client creates a companion ADF to hold the attributes.
The client hides these companion files from the user's view. If a user renames or deletes the orginal file, the client automatically renames or deletes the companion file. However, if a user renames or deletes a file on the server side, the user must also rename the companion file; otherwise, file attributes are lost.
You can modify this behavior with the /NOADF qualifier to the MOUNT
command. The /NOADF qualifier tells the client to handle all files as
STREAM_LF unless a default ADF matches. This mode is only appropriate
for read-only file systems because the client cannot adequately handle
application-created files when /NOADF is operational.
22.214.171.124 Creating Customized Default ADFs
You can create customized default ADFs for special applications. To do so:
> ls -a . .. .$ADF$test.gaf;1 test.gaf
> cp .\$ADF\$test.gaf\;1 gaf.adf
$ COPY GAF.ADF SYS$COMMON:[SYSEXE]TCPIP$GAF.ADF