| Installing and Administering the NFS Client |
When you are 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 under OS/390 and CMS
have had little or no access to files that are located on PCs, workstations,
and other nonmainframe 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.
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 OS/390 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 by using NFS are placed in a separate
name space from traditional OS/390 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.
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 that is 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 Using the Debugger's set Command for information about
the SAS/C Debugger's set search command.
To continue the example, suppose the user now
invokes
the debugger on the mainframe and issues the following set search command:
set search userinclude =
"path:/usr/name/project/headers/%leafname"
The debugger now looks for user include files in the
/usr/name/project/headers
directory on the remote workstation that
is 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.
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 Resource Access Control Facility (RACF) compatible
security system, if one is available, and by a login server that is 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 environment) 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 that are based on the user identification
and the file's permissions.
Copyright © 2001
by SAS Institute Inc., Cary, NC, USA. All rights reserved.
