Trying to add an entity to a request via the Web interface and getting Lock Validation error 2954.
The Web Interface error J123 2954 is equivalent to error ZDDCR425 in the ISPF interface:
ZDDCR425 LOCK NOT MATCHED
Explanation: The implementation details don't specify a lock name held by this entity.
System Action: None
User Response: Use Entity Access to verify the locks held by the entity.
Check the management-information fields for the current Change Request match one of these locks.
Should you find yourself unable to add an entity to a request because you are stopped by a LOCK NOT MATCHED or LOCK VALIDATION error, you check each of these in order until you find the cause.
(Once you correct the problem, there is no need to continue with additional steps.)
- Verify the lock(s) for this entity in this zone match the corresponding management field values on this request
- If your ETD defines HIGHZONE for this entity type, and LOCK VALIDATE, you also need to check lock values in higher zones.
- If there are no locks set in any higher zone, you may need to check out the entity to set a lock.
- For example: User gets LOCK VALIDATION ERROR trying to add entity to change request to zone D. No entity of this name exists in zone D, but there is one in zone Q with no locks. Check out from zone Q and set lock(s) to match values in this request. Now you should be able to add the entity to the request.
- Ensure there are no active versions of the same entity in another request, such as a failed request.
- If Entity already existed in a failed request. Re-release the failed request and cancel as soon as it goes to BUSY so that it will end up in CANCELED status and entities are not left as active.
- Recreate with ZCITRACE to identify what version of the entity that Alchemist is validating against your request. (See detailed example below)
- Turn on ZCITRACE by specifying a ZCITRACE DD SYSOUT=* in the Alchemist started task.
- It is ideal if you can start Alchemist with ZCITRACE, recreate the problem, stop Alchemist as quickly as possible to minimize the trace output.
- Find the entity that Alchemist is checking against for a lock value.
- Find the error (J1232954)
- Find the previous instance of "NTC"
- Find the previous instance of "SELVER"
- The resulting SELVER=@1234567 is the ccref (change control reference) number that Alchemist is expecting this request to match for locks.
- Check if this version of this entity is visible in Entity Access in this zone or higher.
- Does it have an existing lock? Is it the current version? Do other versions also have locks? Depending upon the scenario, you may need to check out this version to set the appropriate lock or change the lock value on your request.
- If the entity version is NOT visible in Entity Access, run ZBBVPUP to see if it exists in the target and any higher zone.
- For each zone, run ZBBVPUP with this SYSIN, using a mask with the ccref identified in the ZCITRACE: ./ PRINT FILE(' prefix.zone .ZCL') ./ NAME(*@1234567) ./ LIST(DIRECTORY).
- Since you cannot see this entity in Entity Access, it is likely an orphan from some abandoned request. In any case, it is not useful for any purpose and you can delete it. ./ DELETE FILE(' prefix.zone .ZCL') ./ NAME(*@1234567) ./ LIST(DIRECTORY).
- If you are feeling cautious, you can rename it instead. Don't forget to go back and delete it once you verify that not having the entity is not causing any problems.
- Check if there are any failed requests that may or may not be archived with active versions of this entity
- You can run ZCELUIMP to identify any of these situations.
- It may take a long time to run if you have a large REQUEST and/or ZCL.
- Alchemist Administrator's Guide has details on running this utility and interpreting the output.
EXAMPLE regarding step 3 above :
To find the ccref in ZCITRACE that Alchemist is checking against for locks:
f j1232954;f ntc prev;f selver prev
In this example finds ccref @0251451: