Chapter Contents

Previous

Next
Using the NFS Client

Accessing Remote File Systems

Logging on establishes UID and GID information. The next step is to mount the remote file systems that you want to access.

Because the SAS/C CSL NFS client feature runs totally within your user address space under OS/390, or on a virtual machine under CMS, you must mount remote file systems before accessing NFS files. A number of facilities are provided to make this process as transparent as possible. Mounts can occur in three ways:

At sites with standardized configurations, a series of mounts may be provided automatically. In this case, you do not need to do additional work unless you want a different configuration.


Saving File-System Context

Assuming that you are doing the configuration yourself, one of the first things to decide is the duration of your mounts. That is, do you want mounts and directory changes from one program to be preserved for the next program that is run? Mounts and directory changes form a file system context that may be restricted to the execution of a particular program or may be shared serially by programs under TSO or CMS.

The serial sharing of file system context is accomplished by using the mnttab file. Not sharing context can be easier. When only a few file systems are mounted, reissuing the mounts in each program can be faster than reading and writing the mnttab file. NFS mounts are very fast and involve minimal processing on the server.

Unfortunately, processing the mnttab file at program startup and shutdown adds noticeable delays to otherwise fast commands and programs. The NFS sample programs cd , pwd , and ls illustrate this. Overall NFS performance is much better when a single program does many operations. Sharing is required, however, if working directory changes are to be preserved from one program to the next. You should always save the file-system context when you are working with the SAS/C Debugger in a cross-development environment.

You specify serial sharing of file system context by setting the ETC_MNTTAB environment variable to the name of a file to contain the context. For example, under TSO, you might use the value TSO:ETC.MNTTAB. This creates a file tsoprefix.ETC.MNTTAB. Under TSO you set the value by using the PUTENV command. Allocating a DDname of ETCMNTTB has the same effect under OS/390 batch and may be more convenient. Under CMS, you can set the value by using GLOBALV commands with the CENV group. See SAS/C Compiler and Library User's Guide and SAS/C Library Reference, Volume 1 for more information about using environment variables with the SAS/C Compiler.

You do not need to create the mnttab file yourself. The NFS client library will create it automatically. It will also be deleted each time you log on to the NFS server. Note that, unlike the conceptually similar UNIX /etc/mnttab file, this file has a binary format. It also contains information, notably the current working directory, that is held by the kernel in UNIX.

Finally, the mnttab file cannot be shared simultaneously by many programs. If you are managing multiple programs that use NFS concurrently, either set up multiple mnttab files or set them up not to save context at all.

To avoid serial sharing, do not set the environment variable. In this case, the MOUNT command and the sample cd command appear to have no effect, because the changes that they request are not saved when they end. When not sharing file system context, you invoke all your mounts with the fstab configuration file.


Setting Up an fstab Configuration File

When NFS starts with no mnttab file available, either because there is no serial sharing of file system context or because NFS has not yet been used, the NFS client library searches for an fstab configuration file that specifies which initial mounts to perform. The fstab file removes the need to issue mount commands manually each time NFS is used.

The fstab configuration file format is identical to that used in most UNIX systems. It should have a series of lines that specify mount points that use the following format:

server : directory mount-point
type options

Fields are separated by white space, and any fields that follow the options parameter are ignored. You can also include comments in the fstab configuration file. The pound (#) character that appears at the beginning of a line or that is preceded by white space indicates that the rest of the line is a comment.

For NFS file systems, the device is specified as a server name that is followed by a colon (:), which is followed by the name of the directory to mount. This name must be a physical file on the server.

Note:    It must not be a name that was created by NFS client features of the server. This is a common source of confusion. Users of the NFS server are often accustomed to specifying directory names that are not physical directories on their system. As discussed earlier, the design of NFS does not cause these names to be propagated automatically to NFS clients of that server.  [cautionend]
The mount-point parameter must be a pathname in the directory hierarchy that is being created on the mainframe. In order for the first directory to be mounted, the mount point must be a slash (/), which indicates the root directory. Following NFS conventions, later mount points must be actual directories in a file system that have already been mounted. The directories that are being mounted then obscure the contents of the directory that they are mounted on.

The type parameter must be nfs . As in UNIX, the table definition is generalized to accommodate multiple types of file systems; however, at present only NFS file systems are supported.

Mount options, which are described in Mount Options, generally are not needed.

Example fstab configuration file shows a typical fstab configuration file:

Example fstab configuration file

# My NFS setup
byrd.unx:/local/u/bill  /       nfs     #No mount options
server.unx:/tools       /tools  nfs ro  # Mount tools read-only
elgar.langdev:c:/       /lang   nfs     # Mount from OS/2

This example assumes that the /local/u/bill directory on byrd.unx contains subdirectories that are called tools and lang . Presumably these are empty directories that were set up to serve as mount points for the second and third mounts. If they are not empty, any contents that they have are obscured to the mainframe user by the second and third mounts. Instead of seeing the contents of the local directories, the corresponding directory trees from the /tools directory on server.unx and the c:/ directory on elgar.langdev are seen by the mainframe user at those locations.

The fstab data set is located in the following manner:

  1. If there is an environment variable that is named ETC_FSTAB , its value is used. Note that the default style is ddn: . Remember to include the style at the beginning of the name if you want a different one, such as in tso:etc.fstab .

  2. Under OS/390, if there is a DDname of ETCFSTAB, it will be used.

  3. The next data set in the sequence depends on the operating environment that you are working under.

  4. If you are working under OS/390, zappedprefix.ETC.FSTAB is used. The zappedprefix defaults to NFS if it is not zapped, and it can be overridden by the NFS_PREFIX environment variable.

The fstab data set cannot itself be accessed with the path: prefix. See Accessing Files for information about the path: prefix.


Mount Options

Mount options control the operation of mounting the file system, as well as the file system's characteristics for subsequent use. The options must be separated by commas, with no intervening spaces. They can be specified in either uppercase or lowercase. Mount options are not usually needed; the defaults are generally adequate.

Mount Options contains the options that you can specify.

Mount Options
Option Description
RW Indicates that the file system is read/write. This is the default setting.
RO Indicates that the file system is read-only.
DELTAMIN Indicates the time adjustment in minutes to be applied to time stamps on the given file system. This can be useful when file systems are set to operate in different time zones. This value can be either positive or negative.
RETRY=n Number of retries for mount failures. The default is 1. The parameter affects only mount attempts. It does not affect other operations such as read and write. (See RETRANS for other operations.)
RWSIZE=nnK Reads and writes buffer size. The default is 4K. The maximum allowed is 1024K.
TIMEO=n Controls the timeout interval in tenths of a second used between retransmission attempts. The actual timeout interval begins at n tenths of a second and is doubled for each retransmission. The default TIMEO value is 7. (See also RETRANS.)
RETRANS=n Specifies the number of NFS retransmissions. The default is 4. The timeout is multiplied by 2 for each successive retransmission.
SOFT Specifies that a transmission attempt should be abandoned after a complete set of retransmissions fails. This is the default.
HARD Specifies that a transmission attempt should not be abandoned after a complete set of retransmissions fails. If HARD is specified, the retransmission process is started over again after each set of transmissions is completed.
TEXT Performs ASCII or EBCDIC translation on all files. An ASCII-to-EBCDIC translation is performed when the file is read from the server, and an EBCDIC-to-ASCII translation is performed when the file is written to the server.
BINARY Always leaves data in untranslated, binary form.
XLATE Gives the name of a loadable translate table to be used for ASCII and EBCDIC translation in this file system. This translation affects data that are read and written. By default, NFS data are translated using the IBM code page 1047 standard. The table is built in much the same manner as SAS/C CSL RPC translate tables. (See the description of the xdr_string function in SAS Technical Report C-113, SAS/C Connectivity Support Library, Release 1.00.) The only difference is that you may choose any load module name and then specify it here. If you have created an L$NAEXDR table for RPC, you may specify it to get the same translations for NFS data as for RPC strings. The XLATE option does not affect pathnames, which are controlled by the RPC L$NAEXDR translate table if present. If the translate table is not present, use the code page 1047 standard.

The TEXT and BINARY mount options enable you to override the defaults, which are determined by the debugger when it accesses a file on the workstation. However, we recommend using them only in unusual situations. When using the SAS/C Debugger, the settings defined by the debugger are generally appropriate.


Chapter Contents

Previous

Next

Top of Page

Copyright © 2001 by SAS Institute Inc., Cary, NC, USA. All rights reserved.