The following processing characteristics and restrictions must be considered when using the path name prefix processing support provided by the NFS Server Site Attributes:

1. 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.
2. 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.
3. 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.

4. 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.
5. 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.
6. 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.
7. 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.
8. 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.