LOCK Command

The LOCK command marks a member as LOCKed. When a member is LOCKed, you cannot modify its data, attributes, or comment in any way (regardless of status) unless your user ID matches the user ID associated with the ++LOCK.
capan146
The LOCK command marks a member as LOCKed. When a member is LOCKed, you cannot modify its data, attributes, or comment in any way (regardless of status) unless your user ID matches the user ID associated with the ++LOCK.
  • After a member is LOCKed, only the LOCKing user ID can UNLOCK it. A date and time stamp is also placed on the member at the time of the LOCK command.
  • Batch
    Panvalet
    uses the user ID specified on the JOB JCL statement. If the user ID is not specified, the LOCK user ID is only present for jobs that are submitted by the internal reader in an environment that uses a security package that propagates the TSO user ID. See the LOCK/UNLOCK Considerations section for more information. Some known environments that provide
    Panvalet
    with user ID information are: IBM's RACF,
    ACF2
    , and
    Top Secret
    .
Syntax
++LOCK name1[,name2]
Parameters
  • name1
    The name of the member you want to LOCK.
  • name2
    This optional parameter allows you to specify a range of members to LOCK.
LOCK/UNLOCK Considerations
LOCKing a member provides prolonged member integrity in that you can protect a member from modification for long periods of time (for example, days or weeks), until you UNLOCK it.
This facility is useful in installations where members are moved to different environments to be modified. For example, the member can be moved to a "work" library on the same system, a library located on a different machine or operating system (VM, VSE), or downloaded to a PC workstation environment.
As of the release 14.2 of
Panvalet
, the user ID is part of the LOCK/UNLOCK facility. The user ID is a one- to seven-character alphanumeric ID that uniquely identifies a user. This user ID identifies the user who LOCKs or attempts to UNLOCK a member in a
Panvalet
library.
Whenever a member is LOCKed, the user ID of the user (through TSO) or JOB (through batch) is stored in the library for the member that gets LOCKed. To successfully UNLOCK a LOCKed member, the user ID requesting the UNLOCK must match the user ID stored when the member was LOCKed.
Users can still access a LOCKed member; however, a user cannot modify the member's data, attributes, and comment unless the user ID associated with the LOCK matches that of the user attempting the modification, or the user ID associated with the LOCK UNLOCKs it.
LOCKing a member is an action against that member which does not change any member attributes. After UNLOCKing a LOCKed member, you can process the member just as it was prior to LOCKing.
In the z/OS operating environment, the user ID that
Panvalet
batch uses to identify who is LOCKing or UNLOCKing a member can come from various sources, such as the:
  • TSO logon user ID when using TSO or the
    Panvalet
    /ISPF option.
  • USER parameter on the z/OS JOB card.
  • Security package if the option is enabled to automatically fill in the USER parameter for jobs that are submitted to batch or automatically store user ID into the z/OS JCT, PSCB, or ASCB internal control blocks. (RACF,
    ACF2
    or
    Top Secret
    provide the user ID.)
  • Site-specific user MODs that do what a security package does for user ID.
"Submitted to batch" from a TSO session on the same system where the batch program runs can fill in some user ID fields that might not be filled in if the job (JCL) is submitted through a TSO from a different system, or if submitted through a different environment like VM/CMS, VSE, PC workstation, and so on.
Refer to your security system administrator, network administrator, or systems programmer for further information.
If you do not have a security package or user MODs to automatically fill in the USER parameter for jobs that are submitted to batch, or automatically fill user ID in key control blocks (JCTUSER, ASXBUSER, PSCBUSER) for jobs that are submitted to batch without a USER parameter, then
Panvalet
batch is presented with a user ID of blanks. When
Panvalet
batch is executed in
Panvalet
TSO and ISPF environments, it uses the TSO user logon ID for LOCKs and UNLOCKs. The stored user IDs are not blanks for the member. Therefore, the same user doing LOCKs in both TSO and batch ends up with blank user IDs when LOCKed in batch, and TSO user IDs when LOCKed from TSO or ISPF. This requires members to be UNLOCKed in the same environment (TSO or batch) in which they were LOCKed because the user ID of the person requesting the UNLOCK must match the user ID stored when the member was LOCKed. However, any member LOCKed with a blank user ID, can be UNLOCKed by any other user ID, even if it does not match the blank user ID.
In the VSE operating environment, the ++PASS command passes the user ID to
Panvalet
.