Capabilities and restrictions for Version 4 NFS server processing in a sysplex environment

Starting with z/OS® V1R7, z/OS UNIX supports Version 4 NFS server protocols. This support includes new v_open() and v_close() callable services, including support for file sharing semantics (share reservations), and enhanced lock control interfaces and functionality (provided by the v_lockctl() callable service).

The following capabilities and restrictions apply to Version 4 NFS server processing in a sysplex environment:

To open a file with share reservations, the file must be owned by a system at the z/OS V1R7 level or higher. The following applies to files that are owned by remote systems:
- If a file is owned by a remote system that supports share reservations, they will be enforced at the owning system for all open requests within the sysplex. At the owning system, an open request from a down-level remote system behaves just like a local open request.
- If a file is owned by a remote system that does not support share reservations, the v_open() fails with return code EOPNOTSUPP, reason code JrNoShrsAtOwner. Move the file system to a sysplex member that supports share reservations.
A file system that has active share reservations on any of its files can be moved to another system that supports share reservations and those share reservations will move with the files and continue to be enforced at the new owning system.
A file system cannot be moved to a down-level system while there are active share reservations on any file in that file system. Any attempt to do so will fail with return code EINVAL, reason code JrCantMoveShares. Either move the file system to a sysplex member that does support share reservations, stop the NFS client applications that are holding share reservations on the files, or wait for those applications to complete.
When share reservations exist on files that are owned by a remote system and that system crashes, the following occurs:
- If the file system is taken over by another system that supports share reservations, the reservations will be reestablished and enforced at the new owning system.
- If the file system is taken over by another system that does not support share reservations, the share reservations can no longer be enforced. The open tokens for the affected files will be invalidated and subsequent operations with those open tokens will be rejected with return code EIO, reason code JrShrsLost. Move the file system to a sysplex member that supports share reservations; the files can then be reopened as they were before.
Note: You can use the AUTOMOVE parameter on the MOUNT command to restrict such takeovers only to systems that support share reservations.
When a file system is owned by a remote system that does not support the Version 4 NFS server protocols, the following restrictions apply:
- Enhanced blocker information is not available when a byte range lock request cannot be granted. In such a case, the output BRLM_Rangelock structure will contain zeros.
- The new purge locks interfaces are not supported unless the masks map to the old functionality—that is, all clients and threads or all threads at a client. TID subsetting cannot be used.
- The UnLoadLocks function is not supported.