Types of opens

This topic contains background information about the various types of open operations.

The traditional POSIX open() function requests read or write access to a file, and files are shared among all users who independently open them.
An open/close protocol was added to the NFS architecture in Version 4. The z/OS® V4 NFS Server invokes v_open() in support of V4 clients. v_open() can be used to place Share Reservations on a file for Windows work stations.
The distinctions between open() and V4 v_open() are not significant to the PFS. Both are passed on vn_open as type VNOPEN_FILE. When close() or v_close() is issued the resulting vn_close will also be of this type.
Older V3 clients can use the Network Lock Manager Share function to place Share Reservations on files, but since NLM and NFS are not necessarily integrated on a server the V3 NLM Shares do not inhibit reading and writing. These NLM Shares are advisory locks and only contend with each other at the time they are obtained. V4 Shares are mandatory locks and they also inhibit any conflicting reading or writing by V3 clients. Because of this difference in enforcement for reads and writes that occur outside of an open context, these NLM Shares are passed to the PFS on vn_open as type VNOPEN_NLM_SHR. When the NLM Unshare is specified a corresponding vn_close is passed to the PFS with this same type.
V4 NFS clients can reduce the number of flows to a server by sharing opens on that server among its local users. When a file is subsequently opened for more access or with more reservations than the client has so far established on the server, the client must upgrade its open context on the server. Conversely, when the file is closed locally on the client and it no longer needs all of the access rights or reservations it has on the server, it can downgrade its open context on server. These upgrades appear in the PFS as a vn_open and the downgrades appear as a vn_close of the same types as described previously.
These upgrades and downgrades are not necessarily paired. Consequently, when Shares are supported by the PFS there may not be the same number of vn_closes as vn_opens for a given file. See Close processing for more information. An upgrade of the deny modes appears in the PFS as a vn_open with no access flags turned on, and there should be no SAF Check Access security call made when there is no new access requested.
The LFS issues Internal Opens in support of file servers such as NFS V3 and SMB. These servers obtain Vnode Tokens for the files they reference, usually through v_lookup or v_vget, and then proceed to read and write to these files without ever explicitly opening them. The purpose of the Internal Open is to keep the PFS's open counter greater than 0 while the server has an active Vnode Token, so that if the file is removed by the server or by a local user, the file data will not be discarded until after the server has finished and called v_rel(). These Internal Opens do not effect or interact with Share Reservations in any way and so are passed to the PFS as type VNOPEN_INTERNAL. The later reads and writes from this server are outside of an open context and are checked against the corresponding Share Reservations that may inhibit that action. When the Vnode Token is released with v_rel the LFS does an internal close of this same type.