Installing and Administering the NFS Client

SAS/C NFS Client Overview

When working in a distributed environment without file sharing, the barrier between systems can become problematic. Files that are needed on one system often reside on another. The solution of transferring the entire file, using File Transfer Protocol (FTP) for example, is practical if the file is small and seldom changes, but becomes much more laborious when this is not the case.

Traditionally, programs running on MVS and CMS have had little or no access to files located on PCs, workstations, and other non-mainframe computers. The SAS/C CSL NFS client support changes this situation. For example, in the cross-development environment you can run the SAS/C Debugger on the mainframe while your source and debugger files reside on a workstation.

Accessing Files

The SAS/C CSL NFS client transient libraries enable a new filename style prefix, path: , in SAS/C filenames. In the same way that an MVS program can use the dsn: prefix to open a file by data set name, the program can now open an NFS file with the path: prefix. Thus, files that are accessed using NFS are placed in a separate name space from traditional MVS or CMS files. This separation is due to differences in file system organizations, such as directories versus partitioned data sets, rather than the fact that one group is local and the other is remote.

Mounting Directories

SAS/C CSL functions and configuration files are available to mount directories in the mainframe environment. As multiple mounts are established from one or more remote machines, the CSL NFS client library maintains a unified hierarchical view of the resultant directory structure. With the CSL NFS client, mounts are the responsibility of the individual user, not of a system administrator.

For example, a configuration file with the following line can be used if the user wants to access a UNIX root directory / on a machine named acct.langdev.abc.com .

acct.langdev.abc.com:/ / nfs

This indicates that the root of the acct.langdev.abc.com machine should be mounted as the root directory on the mainframe, thus enabling a debugger user to specify set search commands relative to the mount point. (See Chapter 9, "Cross-Debugging" for information about the SAS/C Debugger's set search command.)

To continue our example, suppose the user now invokes the debugger on the mainframe and enters the following set search command:

set search userinclude =
   "path:/usr/name/project/headers/%leafname"

The debugger will now look for user include files in the /usr/name/project/headers directory on the remote workstation named acct.langdev.abc.com .

In a more complicated setup, many different UNIX workstation file systems can be mounted together. The overall organization is the responsibility of the mainframe user, and the pathname for a particular file will often differ from what would be used on any of the systems individually.

File Security

The CSL NFS client enforces security controls that prevent unauthorized access to files on the server. Before the user can access an NFS file, the user identification must be authorized by the local RACF compatible security system, if one is available, and by a login server running on a UNIX system. If a local security system is available, this login process can be invoked automatically by the CSL library. If not, the user must supply a UNIX, or other NFS server operating system, username, and password.

In either case, the NFS client software maintains the standard UNIX, or POSIX, User Identification (UID) and Group Identification (GID) numbers for the duration of the user's session. The NFS client software controls access to remote files based on the user identification and the file's permissions.

Chapter Contents
Previous
Next
Top of Page