|
FunctionThe vn_lockctl operation conveys
a byte range locking command for a file.
Input parameter formatvn_lockctl (Token_structure,
OSI_structure,
Audit_structure,
LockCommand,
Vlock_length,
Vlock,
Return_value,
Return_code,
Reason_code)
Parameters- Token_structure
- Supplied parameter
- Type:
- TOKSTR
- Length:
- Specified by TOKSTR.ts_hdr.cblen.
The Token_structure represents the file (vnode)
that is being operated on. It contains the PFS's initialization token,
mount token, and the file token. Refer to LFS/PFS control block structure for
a discussion of this structure, and to the TOKSTR typedef in BPXYPFSI
in Interface structures for C language servers and clients for its mapping.
- OSI_structure
- Supplied and returned parameter
- Type:
- OSI
- Length:
- Specified by OSI.osi_hdr.cblen.
The OSI_structure contains information that is used
by the OSI operations that may be called by the PFS. See OSI services for more information.
It also contains
MVS-specific information that needs to be passed to the PFS, including
SMF accounting fields, a work area, a recovery area, and an optional
pointer to an output ATTR structure. For more details on the OSI structure,
see The OSI structure.
This area is mapped by
the OSI typedef in BPXYPFSI in Interface structures for C language servers and clients.
- Audit_structure
- Supplied parameter
- Type:
- CRED
- Length:
- Specified by CRED.cred_hdr.cblen.
The Audit_structure contains information that is
used by the security product for access checks and auditing. It is
passed to most SAF routines that are invoked by the PFS.
Refer
to Security responsibilities and considerations for a discussion of security processing,
and to the CRED typedef in BPXYPFSI in Interface structures for C language servers and clients for
the mapping of this structure.
- LockCommand
- Supplied parameter
- Type:
- Integer
- Length:
- Fullword
The command indicates the function that is to be
performed by the PFS. The values are the same as for the v_lockctl
callable service and are defined in BPXYVFSI. See Interface structures for C language servers and clients.
- Vlock_length
- Supplied parameter
- Type:
- Integer
- Length:
- Fullword
Vlock_length contains the length of the Vlock structure
that is passed.
- Vlock
- Supplied and returned parameter
- Type:
- Structure
- Length:
- Specified by Vlock_length
The Vlock structure contains information about
the locking request. See v_lockctl (BPX1VLO, BPX4VLO) — Lock a file for more information.
- Return_value
- Returned parameter
- Type:
- Integer
- Length:
- Fullword
A fullword in which the vn_lockctl service returns
the results of the operation, as one of the following: - Return_value
- Meaning
- -1
- The operation was not successful. The Return_code and Reason_Code
values must be filled in by the PFS when Return_value is -1.
- 0
- The operation was successful.
- Return_code
- Returned parameter
- Type:
- Integer
- Length:
- Fullword
A fullword in which the vn_lockctl operation stores
the return code. The vn_lockctl operation returns Return_code only
if Return_value is -1. For a complete list of supported
return code values, see z/OS UNIX System Services Messages and Codes.
The vn_lockctl operation should support at least
the following error values: Return_code |
Explanation |
---|
EAGAIN |
The Lock command was requested, but the lock
conflicts with a lock on an overlapping part of the file that is already
set by another locker. |
EDEADLK |
The LockWait command was requested, but the
potential for deadlock was detected. |
EINTR |
A LockWait request was interrupted by a signal. |
EINVAL |
Parameter error. |
ENOSYS |
Returned for files that must be locked locally.
After this return code is encountered, the current and all subsequent
lock requests for this file are sent to the local BRLM. This remains
in effect until the file is inactivated. |
- Reason_code
- Returned parameter
- Type:
- Integer
- Length:
- Fullword
A fullword in which the vn_lockctl operation stores
the reason code. The vn_lockctl operation returns Reason_code only
if Return_value is -1. Reason_code further qualifies
the Return_code value. These reason codes are documented by the PFS.
Implementation notes- Overview of vn_lockctl processing
Refer to the fcntl() function in z/OS XL C/C++ Language Reference for
an overview of byte range locking and how applications use it.
See v_lockctl (BPX1VLO, BPX4VLO) — Lock a file for details on the Vlock structure and its
usage.
- Serialization provided by the LFS
- The vn_lockctl operation is invoked with a shared latch held on
the vnode of the file.
- Security calls to be made by the PFS
- None
- Specific processing notes
- The PFS may support locking for just some of its files. Mt_nolocking
can be returned from vfs_mount to turn off vn_lockctl for an entire
file system. Vn_lockctl can be turned off for one file by rejecting
any vn_lockctl request with RC=ENOSYS. Normal local BRLM locking is
done in cases where vn_lockctl is not called.
- Vn_lockctl is called for the following locking operations: VL_LOCK,
VL_LOCKWAIT, VL_UNLOCK, VL_QUERY, VL_UNREGLOCKER. These are described
in v_lockctl (BPX1VLO, BPX4VLO) — Lock a file.
- The object being locked is represented by the Vnode of the operation.
The Object ID in the Vlok is usually not filled in.
- Locker Registration: To speed up future locking operations for
a process, the PFS can return a token in vl_lockertok that the LFS
saves and passes back to the PFS on later vn_lockctl calls from this
same process. Vl_lockertok will be zeros unless a prior Locker Token
has been saved. A new Locker Token can be returned on vn_lockctl
requests that fail; for example, with VL_LOCK when the lock can not
be granted. The Locker Token is also passed to the PFS on vn_rdwr,
vn_trunc, and vn_settattr (File Size Change) calls when the file involved
is one for which vn_lockctl would be called for locking requests.
When this process terminates, vn_lockctl is called for the VL_UNREGLOCKER
operation so it can clean up any resources that may be associated
with the token. There is no file associated with this operation, so
the Vnode passed on the call is not significant and will usually be
the root vnode of one of the file systems that is mounted on this
PFS.
- Object Registration: The object being locked is fundamentally
represented by the Vnode of the operation, but if the PFS returns
a non-zero value in vl_objtok the LFS will save this value in the
Vnode and pass it back to the PFS on all future locking operations
for this object. A new Object Token can be returned on vn_lockctl
requests that fail; for example, with VL_LOCK when the lock can not
be granted. There is no explicit Object unregistration. Any locking
related resources for an object are normally cleaned up as part of
vn_inact processing.
- The Locker ID passed to vn_lockctl for normal POSIX fcntl() users
has the user's Process ID (PID) in the vl_clientpid field. The vl_serverpid
and vl_clienttid fields will be zeros. In general, the full 16-byte
Locker ID represents the individual entity that is requesting the
lock. This Locker ID contends with all other 16-byte Locker ID entities
for these locks. Only the first 8-bytes of the Locker ID are used
for implicit Locker registration and explicit unregistration. Threads
would be considered to be part of the registered process.
- For VL_QUERY, only the POSIX Brlk structure can be returned to
the fcntl() caller, so the extended blocker information discussed
under v_lockctl (BPX1VLO, BPX4VLO) — Lock a file for the vl_blockinglock field
is not used with vn_lockctl. The only information returned about
the blocking locker by the LFS for fcntl() is a 1-word Process ID.
If the blocking locker is another local POSIX process the PFS should
return that PID in the Brlk structure; otherwise the PFS should return
the PFS’s Colony PID.
|