|
The following processing characteristics and restrictions must
be considered when using the path name prefix processing support provided
by the NFS Server Site Attributes:
- When both path options are available based on the IMPPREFIX site
attribute (when IMPPREFIX = mvs,hfs or hfs,mvs), only the existence
or nonexistence of the first path name qualifier is used to determine
whether the second option is tried. That is, if the first path qualifier
exists, but the next one does not, the object is considered not to
exist and the mount/lookup fails.
- Prior to V1R11, an MVS mount to an HLQ (for example, a.b.c) for
which no data sets exist was considered valid and would mount to that
HLQ, allowing the first data set to be created via NFS. As of V1R11,
if the IMPPREFIX site attribute specifies mvs,hfs, NFS Version 4 mounts
to such an HLQ fail on the MVS side and then attempt to mount z/OS
UNIX node /a.b.c. If that z/OS UNIX node does not exist, the mount
fails. If this behavior is not desired, either an MVS prefix must
be specified on the path or one of the other IMPPREFIX site attribute
values must be specified.
- For IMPPREFIX(HFS,MVS), if the object does not exist (neither
z/OS UNIX nor MVS), it creates the mount point as a new MVS HLQ with
no entries, just as an MVS mount does in prior releases.
Conversely,
for IMPPREFIX(MVS, HFS), if the object does not exist (neither z/OS
UNIX nor MVS), it tries MVS, then z/OS UNIX, then fail, just as a
z/OS UNIX mount for a non-existent object did prior to V1R11.
Once
NFS has switched to option 2, it cannot switch back to option 1.
- For NFS Version 2 or Version 3 mount requests, NFS clients send
the entire mount path to the NFS server as a single string. By contrast,
for NFS Version 4 mount requests, NFS clients send a series of lookup
requests (there is no mount request) to the NFS server for one path
qualifier at a time. Consequently, the NFS server does not know whether
additional path qualifiers follow. This can produce unexpected results.
- If a mount request is issued as an NFS Version 2 or Version 3
mount request, the path is handled as a single string entity and is
resolved by z/OS UNIX resolving the symbolic link to the z/OS UNIX
/a directory, ignoring the IMPPREFIX setting. This is effectively
no change from prior releases.
The same is true for NFS Version
4 mount requests if the symbolic link is the last name in the path
and it is followed by some processing attributes.
Note: If
the NFS client is z/OS there will always be at least one processing
attribute, automatically added by the client identifying it as z/OS.
However, if the mount request is issued as an NFS Version
4 mount request and the symbolic link is not the last name in the
path, or it is not followed by any processing attributes, then the
symbolic link will be identified as such back to the NFS client.
The client will then read the link data and reinitiate the path resolution.
In this case, assuming the link is defined as an absolute path, then
the path type resolution will come into play based on whether a prefix
is included and based on the implicit prefix resolution heuristic.
Note: This can cause the symbolic link to resolve into
MVS space, not just z/OS UNIX space.
- The implicit prefix heuristic also applies to the exports file;
that is, for export entries that do not include an explicit prefix,
the IMPPREFIX( ) site attribute is used to determine the specified
path. If both the HFS and the MVS options are specified, the export
entry applies to both types of file systems, assuming that the specified
entry exists in both file system spaces.
- When the NFS Server restarts, it attempts to recover mount points
recorded in the MHDB. If the HFS or MVS prefix and/or implicit prefix
site attributes were changed before the restart, the new mount points
will reflect the new HFS and MVS prefixes. Implicit prefix changes
will have no effect.
NFS Version 4 mount points that were established
without specifying the MVSMNT processing attribute were not recorded
in the MHDB. The NFS Client will attempt to re-establish these mount
points when it receives a stale file handle response from the NFS
Server. However, the NFS Client has no knowledge of the changed prefix
site attributes and will use the original mount name string in this
attempt. This can result in the NFS Client not being able to reestablish
the mount points.
Note: This statement only applies when
the NFS server prefix site attributes are changed during the server
restart. Otherwise, the NFS client should be able to re-establish
the mount points.
- If the IMPPREFIX(NONE) Site Attribute is specified, all path
names, including those in the exports file (if used), must be specified
with a prefix.
|