This chapter describes how to configure and maintain the MultiNet NFS client, which allows users of OpenVMS client computers to access files on a variety of server computers.
This chapter refers to the MultiNet NFS client and NFS server software as the NFS client and NFS server and the OpenVMS client system and server system as the client and server.
The MultiNet NFS client is an OpenVMS implementation of the Network File System (NFS) protocol. It allows client hosts running the OpenVMS operating system to remotely access files on a variety of server computers that use different operating systems. To users on an OpenVMS client system, all mounting and access operations are transparent, and mounted directories and files appear as native FILES-11 volumes.
The MultiNet NFS client software allows an OpenVMS system to access file systems made available to the network by many types of server systems, including:
· UNIX/Linux
· Microsoft Windows
· OpenVMS systems running the MultiNet NFS server
The client identifies each file system by the name of its mount point on the server, which is the name of the device or directory at the top of the file system hierarchy. When mounting the file system, the client connects the mount point to a mount device in its own hierarchy; for example, NFS2:. Through this connection, all files below the mount point are available to client users as if they resided on the mount device.
The client converts all mounted directory and file structures, contents, and names to the format required by OpenVMS automatically. For example, a UNIX file named:
/usr/joe/.login
appears to an OpenVMS client user as:
DISK$UNIX:[USR.JOE].LOGIN;1
The MultiNet NFS client can convert most valid UNIX file names to valid OpenVMS names and vice versa. See the Storing OpenVMS File Names on an NFS Server section for a complete description of the MultiNet NFS client file-naming conventions.
NFS server systems identify each of their users to the network by a pair of UNIX or UNIX-style user ID (UID) and group ID (GID) codes. During an access operation, the client translates back and forth between the user's OpenVMS UIC (user identification code) and UID/GID pair.
For example, a user named Moore has an account on a UNIX server with a UID of 504 and a GID of 10. The UID and GID are mapped on the OpenVMS client to a user name BMOORE with a UIC consisting of the userid 504 and group affiliation 10.
When the NFS client ACP (ancillary control process) starts, it reads the NFS.CONFIGURATION file, including the UID translations list. The client uses the list to translate each OpenVMS user name to its UID/GID pair and builds a translation table that maps UID/GID pairs to their corresponding OpenVMS UICs.
As described in the following sections, you must create and maintain the UID translation list that maps each user's OpenVMS user name to a UID/GID pair. For file protections to work properly, mappings must be both unique and consistent in each direction (see the Grouping NFS Client Systems for UID/GID Mappings section for a description of exceptions to this rule). You cannot map a single UID to multiple OpenVMS user names, nor can you use a single user name for multiple UIDs.
Whenever the UID/GID to OpenVMS UIC mapping is modified, the NFS client must be reloaded for the changes to take effect. See the Reloading the NFS Client section for more information on restarting the NFS client.
If all the systems in your environment share the same UID/GID pairs, you need not create or specify NFS groups. All translations are automatically placed in the default group, which has no group name associated with it.
In the database that translates between UID/GID pairs and OpenVMS user names, each entry is associated with a particular NFS group. An NFS group is a collection of NFS systems sharing a single set of UID/GID pairs. An example of a collection of systems that would be placed in an NFS group would be a UNIX file server and diskless UNIX client systems which share the same /etc/passwd file. Within an NFS group, the mapping between UID/GID pairs and OpenVMS user names must be one-to-one: you cannot map a single UID/GID to multiple user names, nor can you use a single user name for multiple UID/GIDs. However, duplicate translations may exist between NFS groups.
When the NFS client sends an NFS request to a server, it consults the local NFS group database to determine with which group the server is associated. If the server is not specified explicitly in a group, it is assumed to be in the default group. Once the NFS client has determined the NFS group to which the server belongs, it uses the UID/GID translation list for that group to determine the UID/GID pair to use for a particular local user when accessing files on the server.
Consider the following example. At Example, Inc., the engineering department has a group of UNIX hosts, the sales department has a collection of PCs, and the marketing department has a mix of PCs and UNIX hosts. Each group also has its own UNIX system acting as an NFS server for the group. Unfortunately, the groups did not coordinate with each other when they assigned user names and UID/GID pairs; and none of the groups are willing to change their current configurations. The accounting department, on the other hand, recently purchased a VAX-4000 computer running OpenVMS and the NFS client and wishes to use NFS to access certain personnel data that each department maintains on a local server.
The accounting system manager configures the NFS client on the OpenVMS system as follows:
1. Using the NFS-CONFIG ADD NFS-GROUP command, the system manager creates the three NFS groups ENGINEERING, SALES, and MARKETING, placing the NFS systems in each department in the appropriate NFS group (the default group will be used for systems in the accounting department).
2. Departments create accounts (and hence UID/GID pairs) on their servers that the system manager can map to local OpenVMS user ids.
3. Finally, the system manager uses the NFS Configuration Utility ADD UID-TRANSLATION and ADD NFS-PASSWD-FILE commands to create mappings between OpenVMS user names and UID/GID pairs for each NFS group. See the Adding and Deleting Mappings section for details on specifying these mappings.
When mappings are incomplete or nonexistent, access operations are denied or severely limited.
If any server files or directories are owned by a UID for which there is no mapping, the client handles them as though they were owned by the OpenVMS user DEFAULT ([200,200]). The client grants access only according to the WORLD file protection setting of these files.
If your MultiNet system is running both the NFS client and NFS server, you cannot configure the server to export a file system that has been mounted by the client. The server can export local disks only when the server and client are running on the same system.
Because the NFS client does not completely emulate the "on disk" structure of the OpenVMS file system, some applications that directly read the file system may not work correctly over the NFS client.
|
Note: The NFS client can only mount file systems from OpenVMS systems that are using the NFS server.
|
Finally, you may notice that a file's ID (FID) changes every time the file system is remounted. This happens because the NFS protocol does not allow a local file ID to be stored on the remote host; therefore, each NFS client device (NFSx:) has its own idea of what the FID is. The client keeps a cache of local FIDs which it generates by choosing monotonically increasing numbers. Therefore, a file mounted multiple times in a cluster may have a different FID on each node. This might cause trouble with print queues that execute on a node other than the one that submitted the job.
Although the NFS client supports NFS server disk quotas, it does not support use of the DCL SHOW QUOTA command or the DISKQUOTA utility to examine or manipulate these quotas.
The NFS client supports the standard OWNER, GROUP, and WORLD protections allowing READ, WRITE, EXECUTE, and DELETE access (DELETE access is taken from the WRITE access settings on the server system). Each user has a user account on the OpenVMS client as well as on the server. The NFS client compares the UIC of the user to the owner and protection mask of the directory or file and then grants or denies access, as indicated earlier in the MultiNet NFS Client Use of User IDs section.
OpenVMS Access Control Lists (ACLs) are supported when accessing files on NFS server OpenVMS systems, as well as most UNIX NFS server systems.
The NFS protocol assumes an underlying file system in which files are merely streams of bytes with records delimited by linefeed characters (corresponding to the OpenVMS RMS Stream_LF record format). The NFS client supports storage of non-Stream_LF files on an NFS server through attribute description files and file name-dependent attribute defaults.
When using the NFS client, if you create a non-Stream_LF OpenVMS file or a file with ACLs associated with it on an NFS server, the NFS client automatically creates a companion file to hold the attributes. The companion file is a text file in FDL (File Description Language) format.
The client hides the companion file from the user's view; the user sees only a single file with all of the attributes. If you rename or delete the original file from the client, the client automatically renames or deletes the companion file. However, if you rename or delete a file from the server side, you must also rename the companion file. If you do not, file attributes will be lost, the file will revert to stream attributes, and its contents may become unusable.
For example, if you create the remote indexed sequential file foo.bar, the client creates a second remote file .$fdl$foo.bar to hold the attributes. For details on controlling the NFS client's use of FDL files, see the Advanced NFS Client Mount Options section.
Ordinary text files (Stream_LF files) are stored in UNIX byte-stream format and do not require companion files. If you use the OpenVMS COPY command to copy a non-Stream_LF file to an NFS client mounted disk, the file will be converted automatically to Stream_LF format. To disable this conversion, use the NOSTREAM_CONVERSION option of the NFSMOUNT /SEMANTICS=qualifier.
|
Note: When communicating with a UNIX NFS server system, this option prevents UNIX users from accessing these unconverted files as Stream_LF text files.
|
Certain types of files default to a type other than Stream_LF, and the absence of a companion file implies attributes other than Stream_LF. For example, a *.EXE file defaults to a fixed length 512-byte record file. The below table lists the default file attributes included with MultiNet.
|
File Name |
File Type |
Default File Attributes |
|
*.EXE |
Executable |
Fixed 512-byte records |
|
*.OBJ |
Object File |
Variable-length records |
|
*.OLB |
Object Library |
Fixed 512-byte records |
|
*.MAI |
Mail Folder |
Indexed file, variable-length records |
|
*.MLB |
Macro Library |
Fixed 512-byte records |
|
*.HLB |
Help Library |
Fixed 512-byte records |
|
*.TLB |
Text Library |
Fixed 512-byte records |
|
*.STB |
Symbol Table |
Variable-length records |
|
*.DECW$BOOK |
Bookreader Book |
Variable-length records |
|
*.DECW$FONT |
Bookreader Font |
Sequential file, FORMAT undefined |
|
*.DECW_BOOK |
ULTRIX Book |
Variable-length records |
|
*.UID |
DECwindows UID |
Fixed 4096-byte records w/ CR |
The NFS client uses a special file-naming convention to provide a one-to-one mapping between UNIX and OpenVMS file names. As a result of this convention, there are certain restrictions on names that can be assigned to files accessed using the NFS client.
The NFS client attempts to give OpenVMS users access to all files on servers, even when server file names contain characters not permitted by OpenVMS. To accomplish this, the NFS client performs a mapping between OpenVMS and NFS server file names, using the inverse mapping of the NFS server. This mapping ensures consistency between other NFS clients accessing and creating files using the NFS server, and the NFS client accessing and creating files using other NFS servers. All mapping sequences on the OpenVMS client begin with the escape character "$".
As "$" is the mapping sequence escape character, a real "$" in a file name on the server is mapped to "$$" on the OpenVMS client. For example, the server file name foo$bar.c would map to FOO$$BAR.C on the OpenVMS client.
A "$" followed by a letter (A to Z) in a file name on the client indicates a case-shift in the file name on the server. For server systems like UNIX, which support case-sensitive file names, a file name can begin in lowercase and alternate between uppercase and lowercase. For example, the server file name aCaseSENSITIVEFilename would map to A$C$ASE$SENSITIVEF$ILENAME on the OpenVMS client. A "$" followed by any digit 4 to 9 indicates a mapping as shown below.
|
VMS Char. |
Server Char. |
Hex Value |
VMS Char. |
Server Char. |
Hex Value |
VMS Char. |
Server Char. |
Hex Value |
|
$4A |
^A |
1 |
$5A |
! |
21 |
$7A |
Space |
20 |
|
$4B |
^B |
2 |
$5B |
“ |
22 |
$7B |
; |
3B |
|
$4C |
^C |
3 |
$5C |
# |
23 |
$7C |
< |
3C |
|
$4D |
^D |
4 |
$5E |
% |
25 |
$7D |
= |
3D |
|
$4E |
^E |
5 |
$5F |
& |
26 |
$7E |
> |
3E |
|
$4F |
^F |
6 |
$5G |
‘ |
27 |
$7F |
? |
3F |
|
$4G |
^G |
7 |
$5H |
( |
28 |
|
|
|
|
$4H |
^H |
8 |
$5I |
) |
29 |
$8A |
@ |
40 |
|
$4I |
^I |
9 |
$5J |
* |
2A |
$8B |
[ |
5B |
|
$4J |
^J |
A |
$5K |
+ |
2B |
$8C |
\ |
5C |
|
$4K |
^K |
B |
$5L |
’ |
2C |
$8D |
] |
5D |
|
$4L |
^L |
C |
$5N |
. |
2E |
$8E |
^ |
5E |
|
$4M |
^M |
D |
$5O |
/ |
2F |
|
|
|
|
$4N |
^N |
E |
$5Z |
: |
3A |
$9A |
‘ |
60 |
|
$4O |
^O |
F |
|
|
|
$9B |
{ |
7B |
|
$4P |
^P |
10 |
$6A |
^@ |
00 |
$9C |
| |
7C |
|
$4Q |
^Q |
11 |
$6B |
^[ |
1B |
$9D |
} |
7D |
|
$4R |
^R |
12 |
$6C |
^\ |
1C |
$9E |
~ |
7E |
|
$4S |
^S |
13 |
$6D |
^] |
1D |
$9F |
DEL |
7F |
|
$4T |
^T |
14 |
$6E |
^^ |
1E |
|
|
|
|
$4U |
^U |
16 |
$6F |
^_ |
1F |
|
|
|
|
$4V |
^V |
16 |
|
|
|
|
|
|
|
$4W |
^W |
17 |
|
|
|
|
|
|
|
$4X |
^X |
18 |
|
|
|
|
|
|
|
$4Y |
^Y |
19 |
|
|
|
|
|
|
|
$4Z |
^Z |
1A |
|
|
|
|
|
|
The digit after the dollar sign and the trailing letter indicates the character in the server file name. In the special case of the "dot" character (.), the first dot in the server file name maps directly to a dot in the client OpenVMS file name. Any following dot characters on the server are mapped to the character sequence $5N on the OpenVMS client. In directory files, any dot character in the server file name maps to $5N on the client. For example, the server file name foo.bar#1.old maps to FOO.BAR$5C1$5NOLD on the OpenVMS client (unless foo.bar#1.old is a directory file, in which case it maps to FOO$5NBAR$5C1$5NOLD.DIR on the OpenVMS client).
The NFS client also supports OpenVMS file version numbers. If a file created using the NFS client has a file version number other than 1, the resulting file on the server contains the OpenVMS version number. The highest version of the file is hard-linked to the name without the version number.
Finally, a "$" followed by a three-digit octal number indicates a character in the file name on the server that has the binary value of that three-digit octal number. As all character binary values from 0 to 177 (octal) already have mappings, only characters from 200 to 377 are mapped in this fashion. Thus, the leading digit of the octal number must be either 2 or 3.
The NFS client consists of a device driver and an ACP process that receives requests from the OpenVMS Record Management Services (RMS) and translates them into NFS requests. Because the NFS client is called by RMS, applications using RMS or the standard input/output routines of OpenVMS programming languages do not need to be modified to access files through the NFS client. The NFS client presents a $QIO interface identical to the interface documented in the VMS I/O User's Reference Manual: Part I.
The NFS client includes two top-level protocols that run parallel to each other above a stack of lower-level protocols:
· The Network File System (NFS) protocol is an IP-family protocol that provides remote file system access, handling client queries.
· The Remote Procedure Call (RPC) mount protocol, RPCMOUNT, is used by the NFSMOUNT and NFSDISMOUNT commands to get mount-point information from the server systems.
Underlying the NFS and RPCMOUNT protocols is a stack of protocols:
· The remote Procedure Call (RPC) protocol allows the client to make procedure calls across the network to servers.
· The external Data Representation (XDR) protocol handles architectural differences between the client and server systems, allowing the NFS protocol to communicate between systems with dissimilar architectures.
· The RPC/NFS Lock Manager protocol allows the NFS client to support file-locking (exclusive write access).
· User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and Internet Protocol (IP) are used for the lowest levels of communication.
Traditionally, NFS has only run over UDP. The NFS client also supports communication over TCP. This may provide reliability and performance improvements when communicating with NFS server systems across slow network links or wide area networks (WANs), which suffer from packet loss and delay.
Configuring the NFS client alters the NFS.CONFIGURATION file. This file includes the OpenVMS user name and the UNIX (server) UID and GID for each user of the NFS client.
The initial setup of the NFS client consists of the following operations:
1. Using NFS-CONFIG to provide the client with a basis for translating between each user's OpenVMS client and server user IDs.
2. Mounting remote file systems by using the DCL NFSMOUNT command (requires CMKRNL, SETPRV, SYSPRV, SYSNAM, ALTPRI, DETACH, ACNT, and SYSLCK privileges).
3. Reloading the client.
The following sections describe these client setup operations.
There are four steps to configuring the mapping between the user IDs used for each user by the OpenVMS client and the servers:
1. Invoking the NFS-CONFIG utility.
2. Displaying the current mapping data (optional).
3. Using the utility to set up or modify the mapping.
4. Exiting the utility.
To invoke NFS-CONFIG, enter the following command. In response, NFS-CONFIG reads the current NFS.CONFIGURATION file.
$ MULTINET
CONFIGURE/NFS
MultiNet NFS Configuration Utility 5.6
[Reading in configuration from MULTINET:NFS.CONFIGURATION]
NFS-CONFIG>
If you are modifying an existing client configuration, you might want to display the current UID translations list by displaying the NFS.CONFIGURATION file: The NFS-CONFIG SHOW command displays the file.
NFS-CONFIG>SHOW
The following example shows the type of information in the file. The sample file contains:
· The UID translations list
· Other information that relates only to NFS server operation
NFS-CONFIG>SHOW
UID Translations: VMS Username Unix UID Unix GID
------------ -------- --------
JOHN 10 15
BANZAI 2 40
NFS Passwd Files: MULTINET_ROOT:[MULTINET]NFS.PASSWD
NFS-CONFIG>
For more information about the NFS-CONFIG SHOW command, see the NFS-CONFIG chapter in the MultiNet Administrator's Reference.
There are two methods for adding and deleting mappings of user names to UID/GID pairs. You can combine these methods as needed:
· Add and delete individual mappings with NFS-CONFIG.
· If the system includes UNIX servers whose user names are the same as the OpenVMS user names, you can use one or more /etc/passwd files as the basis for multiple mappings, and add and delete those mappings in groups with NFS-CONFIG.
After creating or modifying the UID Translations list, restart the client to put the changes into effect, as described in the Reloading the NFS Client section.
The ADD UID-TRANSLATION command creates an individual mapping between an OpenVMS user name and a UID/GID pair. For example:
NFS-CONFIG>ADD UID-TRANSLATION JOHN 10 15
To create a mapping between an OpenVMS user name and a UID/GID pair associated with the NFS group MARKETING, use a command like the following example:
NFS-CONFIG>ADD UID-TRANSLATION JOHN 10 15 MARKETING
If you are creating UID/GID pairs, each code must be a positive integer or zero, and each user must have a unique UID. A user of multiple servers must have the same UID for each of the servers or use NFS groups to group together systems sharing the same UID mappings.
To delete these mappings, use the DELETE UID-TRANSLATION command, for example:
NFS-CONFIG>DELETE UID-TRANSLATION JOHN
To delete a mapping associated with an NFS group, for example, the user JOHN in the MARKETING group:
NFS-CONFIG>DELETE UID-TRANSLATION MARKETING/JOHN
Remember that after creating or modifying the UID translation list, you must restart the client to make the changes take effect (see the Reloading the NFS Client section.).
The ADD NFS-GROUP command creates an NFS group. For example:
NFS-CONFIG>ADD NFS-GROUP SALES WHORFIN.EXAMPLE.COM, CC.EXAMPLE.COM
To delete a system from an NFS group, use the DELETE NFS-GROUP command; for example:
NFS-CONFIG>DELETE NFS-GROUP SALES WHORFIN.EXAMPLE.COM
To delete the NFS group itself and all UID/GID mappings associated with the group, use an asterisk (*) for the host specification; for example:
NFS-CONFIG>DELETE NFS-GROUP SALES *
If the UNIX and OpenVMS systems use the same user names, you can use the /etc/passwd files from UNIX NFS servers to create multiple mappings. To create a multi-user mapping, use FTP (or another file transfer utility) to copy the applicable /etc/passwd files from the UNIX systems to the OpenVMS system running NFS client. Then run the NFS Configuration Utility, and use the ADD NFS-PASSWD-FILE command to create the mapping. For example:
NFS-CONFIG>ADD NFS-PASSWD-FILE MULTINET:NFS.PASSWD
To create a multi-user mapping associated with the NFS group MARKETING, you might use the command:
NFS-CONFIG>ADD NFS-PASSWD-FILE MULTINET:NFS.PASSWD1 MARKETING
|
CAUTION! If you add or delete users, or change the mapping between user name and UID/GID in the /etc/passwd file on an NFS server, be sure to make the same change in the NFS passwd file on the client.
|
The following example UID translations list includes both individual mappings and passwd file entries (excerpted from the output of a SHOW command).
NFS Passwd Files: MULTINET:NFS.PASSWD,
MULTINET:NFS.PASSWD2
UID Translations: VMS Username Unix UID Unix GID
------------ -------- --------
JOHN 10 15
BANZAI 2 40
The following example UID translation list includes NFS group entries, individual mappings, and passwd file entries created with the NFS Configuration Utility ADD NFS-GROUP, ADD UID-TRANSLATION, and ADD NFS-PASSWD-FILE commands (excerpted from the output of a SHOW command).
NFS Group Name Members
-------------- -------
ENGINEERING control.example.com,fang.example.com
SALES small-berries.example.com,whorfin.example.com
NFS Passwd Files: ENGINEERING/MULTINET:NFS.PASSWD, MULTINET:NFS.PASSWD2
UID Translations: VMS Username Unix UID Unix GID
------------ -------- --------
JOHN 10 15
BANZAI 2 40
ENGINEERING/MAX 30 10
SALES/TOMMY 30 10
To delete an NFS passwd file entry, use the DELETE NFS-PASSWD-FILE command. For example:
NFS-CONFIG>DELETE NFS-PASSWD-FILE MULTINET:NFS.PASSWD
The final step in performing the first NFS client configuration is to mount the remote file systems that you want client users to access as if they were local files. You can also modify an existing client configuration by mounting or dismounting file systems.
Use the NFSMOUNT command to mount an NFS file system. NFSMOUNT requires CMKRNL, SETPRV, SYSPRV, SYSNAM, ALTPRI, DETACH, ACNT, and SYSLCK privileges. For example:
$ nfsmount
sun::"/ufs" disk$sun
%NFSMOUNT-I-MOUNTED, SUN::/ufs NFS mounted on _NFS2:
$
The example command mounts the file system /ufs which is located on the server sun on the local mount device _NFS2:.
The double quotes are necessary in the sample command because of the special meaning of the slash (/) character in OpenVMS. The quotes are not necessary when mounting a file system exported by another OpenVMS system.
When you dismount a file system, you free the resources used by the NFS client. To dismount a file system, use the NFSDISMOUNT command:
$ nfsdismount mount_device
For example:
$ nfsdismount nfs2:
You can use either the logical name specified in the NFSMOUNT command or the actual NFS device name (such as NFS2:) in the mount_device field of the NFSDISMOUNT command.
Before you can use a new or revised set of UID translations, you must first reload the UID mappings into the NFS client with the DCL command:
$ NFSMOUNT /RELOAD
You may also update the client's UID mappings using NFS-CONFIG with the following command:
NFS-CONFIG>RELOAD
For instructions on using the NFSDISMOUNT and NFSMOUNT commands, see the Mounting and Dismounting File Systems section.
|
Note: If no file systems are mounted, reloading does not work.
|
When the START_MULTINET.COM script executes during MultiNet startup, it checks the MULTINET: directory for the existence of a file named NFS_MOUNT.COM. If this file exists, it will be executed in order to mount any remote file system desired by the system manager. The following example illustrates such a file:
$ SET NOON
$ Show Queue
'F$GetSYI("NODENAME")'_BATCH/Output=Sys$Manager:Nfs_Mount.Tmp/All
$ Open/Read File SYS$MANAGER:NFS_Mount.Tmp
$Loop:
$ Read/End=Done File Line
$ If "''F$Element(1,"
",F$Edit(Line,"TRIM,COMPRESS"))'" .Eqs.
"NFS_MOUNT"
-
Then Goto Skip
$ Goto Loop
$Done:
$ Submit/User=System/Queue='F$GetSYI("NODENAME")'_BATCH -
/NoPrint -
MultiNet:NFS_MOUNT_BATCH -
/Name=NFS_MOUNT/Log=Sys$Manager:NFS_Mount.Log
$Skip:
$ Close File
$ Delete Sys$Manager:NFS_Mount.Tmp;*
This DCL program submits another DCL command file, NFS_MOUNT_BATCH.COM, to the queue node_BATCH to do the work after the system boots.
The following is an example of NFS_MOUNT_BATCH.COM:
$ Verify = 'f$verify(0)
$ Set Proc/Name="NFS Mounter"
$ Purge NFS_MOUNT.Log
$ SET NOON
$ Errors = 0
$!
$! Attempt to mount the CD player on NFS.EXAMPLE.COM
$!
$ IF .Not. F$GetDVI("DISK$CD","EXISTS") Then -
NFSMOUNT/VMS/TRANS=TCP/SOFT NFS.EXAMPLE.COM::DISK$CD: DISK$CD -
/VOLUME="CD_ROM"
$ If .Not. $Status Then Errors = Errors + 1
$!
$! Check the status and requeue job if necessary.
$!
$ If Errors .Eq. 0 Then Exit
$ Submit/User=System/Queue=SYS$BATCH -
/NoPrint /Name=NFS_MOUNT -
MultiNet:NFS_MOUNT_BATCH -
/After="''F$CvTime("+01:00","ABSOLUTE")'"
The NFS client has an NFS_CLIENT_ACP process that assists the driver by performing some operations that are easier to do in a separate process rather than at the driver level.
Because this ACP process is single-threaded, using a single ACP for all NFS devices has a significant drawback. If you have multiple NFS devices mounted to different computer systems and an operation hangs on one system, all of the NFS devices are affected.
Specifying NFSMOUNT /PROCESSOR=UNIQUE creates a separate ACP process for each NFS device. This allows NFS devices to function in parallel so one device does not have to wait for an NFS operation on another device to complete. Multiple ACPs provide for multiple outstanding I/O operations on different devices.
The setting /PROCESSOR=UNIQUE creates a separate NFS_CLIENT_n process for each mount, n is the number of the NFS device (for example, NFS_CLIENT_2, which corresponds to the device NFS2).
The following example illustrates the use of /PROCESSOR=UNIQUE, creating four ACP processes (one for each device):
$ NFSMOUNT
/PROCESSOR=UNIQUE SCROOGE::USERS: SCROOGE$USERS
$ NFSMOUNT /PROCESSOR=UNIQUE PIP::UTIL: PIP$UTIL
$ NFSMOUNT /PROCESSOR=UNIQUE HAVERSHAM::ADMIN:
HAVERSHAM$ADMIN
$ NFSMOUNT /PROCESSOR=UNIQUE MARLEY::ENG:MARLEY$ENG
A setting of /PROCESSOR=SAME=nfs_device assigns the mount to the same ACP process as the specified nfs_device. For example, /PROCESSOR=SAME=NFS3 assigns this mount to the NFS_CLIENT_3 ACP process.
|
Note: The specified device may be either the NFS device name itself (for example, NFS3), or a logical name pointing at the NFS device.
|
Mounts specified without the /PROCESSOR qualifier use the default process NFS_CLIENT_ACP.
Process Software recommends that you use the /PROCESSOR qualifier to group mounts on the remote
server. If the server goes down, access to other servers is not affected. You
can use the
/SOFT qualifier to permit NFS operations to
time-out instead of hanging indefinitely.
The following example illustrates the use of /PROCESSOR=SAME. In this example, all access to the server SCOOBY goes through one ACP process, and all access to PIP goes through another process.
$ NFSMOUNT
/PROCESSOR=UNIQUE SCROOGE::USERS: SCROOGE$USERS
$ NFSMOUNT /PROCESSOR=SAME=SCROOGE$USERS
SCROOGE::DKA100: SCROOGE$DKA100
$ NFSMOUNT /PROCESSOR=UNIQUE PIP::UTIL: PIP$UTIL
$ NFSMOUNT /PROCESSOR=SAME=PIP$UTIL PIP::FOO: PIP$FOO
The OpenVMS BACKUP utility can write a saveset to an NFS-mounted disk, but the NFS client does not support specifying files on an NFS-mounted disk as the input-specifier in a BACKUP command.
BACKUP works with the NFS client in a limited way with the following restrictions:
· BACKUP preserves the UIC it finds on a file. If an NFS UNIX file has a UID that does not map to an OpenVMS UIC, the file is backed up as if it belonged to DEFAULT. When you restore the file, it will belong to the UNIX user nobody (UID -2, GID -2).
· BACKUP does not preserve certain bits of information associated with UNIX (such as the "sticky" or set-UID bits).
· NFS identifies UNIX files using a 32-byte file handle. However, the file handle must be presented to OpenVMS as a 6-byte FID. Because the number of possible 32-byte file handles is much greater than the number of possible 6-byte FIDs, MultiNet must implement a cached mapping scheme. This approach works well with applications that only care about FID consistency as long as the file is accessed. However, some applications (such as BACKUP) expect consistent FIDs for the life of the file.
|
Note: Using BACKUP with NFS-mounted files copies the contents of the files, but does not copy the semantics of files created from foreign operating systems. Process Software recommends backing up OpenVMS files to a remote tape via RMT (Remote Magtape Protocol) using MULTINET RMTALLOC (see Chapter 17).
|
The NFS client uses a number of techniques to map OpenVMS semantics such as file attributes and file version numbers to the underlying UNIX file system present on an NFS server. In using these techniques, it makes the assumption that full UNIX semantics, such as file names and hard links, are available on the NFS server. Failure to provide an NFS server that satisfies these assumptions results in incorrect operation of the NFS client.
NFS servers that do not correctly support the full UNIX file system semantics can be used with the NFS client in a restricted fashion. The /SEMANTICS qualifier to the NFSMOUNT command tells the NFS client that the NFS server does not support certain operations, and these operations should not be attempted. Use of certain /SEMANTICS values will mean that some OpenVMS capabilities will not be available, but the client will still function.
The below table lists each semantic and how it changes the behavior of the NFS client. You can specify more than one semantic on a mount request. For more information on the use of the /SEMANTICS qualifier, refer to the NFSMOUNT command page in the MultiNet Administrator's Reference.
|
Semantics Value |
Description |
|
ADVISORY_CLOSE |
Sends an OpenVMS server a command to close the file when there are no more references to it on the client. |
|
NOFDL_FILES |
Disables the use of .$fdl$ files by the NFS client to store RMS attributes. This option must be used if the NFS server does not allow these file names. Its use severely limits the ability of the NFS client to store record attributes. |
|
NOLINKS |
Normally, the NFS client uses a hard link operation to link the top version of a file name foo.bar;12 to the unversioned name foo.bar for more convenient access from the NFS server side. This option disables creating this hard link and may be used either to reduce the overhead of creating it or if the NFS server does not support hard links. |
|
NOSTREAM_CONVERSION |
Normally, the NFS client converts requests to create Variable Length Record Carriage Return Carriage Control (VAR-CR) files into requests to create Stream files, to ensure that text files can be shared between OpenVMS and UNIX systems. This option disables this conversion. |
|
NOUNIQUE_FILENO |
Specifies that the NFS server does not generate unique file numbers for each file (most NFS servers do). If the client knows that file numbers are unique, it uses a faster algorithm to refresh stale directory entries in the cache. Use of this switch disables the faster refresh algorithm. |
|
NOVERSIONS |
Normally the NFS client stores multiple versions of OpenVMS files by using the semicolon character in the file name on the NFS server side. This option must be used to disable the creation multiple versions of files if the NFS server does not support file names with the semicolon character. |
|
NOVMS_ACCESS_CHECKING |
Specifies that the client should not perform a full OpenVMS access check, including a check for ACLs and security alarms. If this option is not specified, the NFS client will consider ACLs and security alarms when granting or denying access. |
|
PRESERVE_DATES |
Specifies that the client should maintain the file's creation, backup, and expiration dates in an FDL file. For information on storing OpenVMS file attributes in FDL files, see the Storing OpenVMS File Names on an NFS Server section. |
|
UPPER_CASE_DEFAULT |
Assumes file names are in uppercase on the server until it sees the $ character used to toggle case. |
|
VMS_FILENAMES |
Specifies that the NFS client does not perform the usual mapping between OpenVMS and UNIX-style file names. This option can be used to permit all OpenVMS file names to be stored using the NFS client, but its use prevents the NFS client from being used to access files which do not conform to the OpenVMS file name conventions. |
|
VMS_SERVER |
Specifies that the NFS server is an NFS server supporting protocol V3 or later, which supports the OpenVMS-specific extensions to the NFS protocol to store file attributes. If the NFS server does not support these extensions, the mount will fail. This option overrides any other semantics specified. |