z/OS UNIX System Services File System Interface Reference
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


vn_lockctl — Byte range lock control

z/OS UNIX System Services File System Interface Reference
SA23-2285-00

Function

The vn_lockctl operation conveys a byte range locking command for a file.

Environment on entry and exit

See Environment for PFS operations.

Input parameter format

vn_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
  1. 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.
  2. 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.
  3. The object being locked is represented by the Vnode of the operation. The Object ID in the Vlok is usually not filled in.
  4. 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.
  5. 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.
  6. 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.
  7. 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.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014