Other considerations

With a read-only file system, Share Reservations should be accepted but do not have to be enforced.

A vfs_umount for remount may be rejected if any file within that file system has any share reservations.

Share contention in a sysplex generally has to be resolved at some central file system owner, which leads to the following restrictions when there are various release levels in the sysplex:

Share reservations should be rejected with RC=EOPNOTSUPP if the file system's owner does not support them.
Once share reservations have been established, the file system cannot be moved to an owner that does not support reservations. When the file system is moved to an owner that does support reservations, the established reservations should move along with the file system ownership.
If the owning system crashes and the file system is taken over by a system that does support reservations, those reservations that have been established should be reestablished for the new owner.
If the new owner does not support share reservations, the reservations are lost and the opens that are using them have to be invalidated. This can be done by calling osi_getvnode(OSI_STALEOPENS) for each vnode that has share reservations. Once the opens are marked stale, subsequent attempts to use them are rejected by the LFS with RC=EIO and RSN=JrShrsLost.