z/VM: System Messages and Codes Š CP - z/VM - IBM

LCK001 LCK005
LCK001
Explanation: HCPLCK was called to release
ownership of a lock, but failed for one of the following
reasons:
v The lock was not held.
v The lock was not held by the calling VMDBK.
v An attempt was made to do a shared release of a
lock held exclusively.
v An attempt was made to do an exclusive release of a
lock held shared.
v The contents of a lock were overlaid.
User Response: Examine the dump and the trace
table and try to determine what went wrong. Register
R4 points to the lock (a LKWRD, described by
HCPLKWRD COPY). Examine the save area to
determine the calling module. Check that the caller
invoked the appropriate HCPLCK entry point according
to the holding of the lock (shared or exclusive). If an
exclusive release is being performed, check the
LKWSTATE field of the lock. It should contain the
address of the owning VMDBK, OR’ed with
x’80000001’. This VMDBK address should be the same
as the dispatched VMDBK (R11) which is attempting to
do the exclusive release. If these addresses don’t
match, one possibility is that the control was switched
from one VMDBK to another (usually by calling
HCPDSBSW), and that ownership of the lock should
have been transferred beforehand (by calling
HCPDSBPX), but wasn’t. Contact your IBM support
Personnel.
LCK002
Explanation: Entry point HCPLCKAD was called with
the same lockword address in R1 and R2. HCPLCKAD
requires R1 to address a lock already held exclusive,
and requires R2 to address a lock to be obtained
exclusive concurrently.
User Response: Examine the storage dump. R13
points to a save area. Identify the caller by the module
base address (R12) and return address (R14) in the
save area. Look at the system trace table for the
sequence of events that led to the caller’s invoking
HCPLCKAD with two copies of the same lockword
address.
LCK003
Explanation: A lock (or LKWRD, described by
HCPLKWRD COPY) was found to be in an incorrect
state. The first fullword of the LKWRD contains an
incorrect code.
User Response: Examine the dump and try to
determine how the incorrect value came to be stored in
the LKWRD. Register R4 points to the LKWRD. Contact
your IBM support Personnel.
68 z/VM: System Messages and Codes — CP
LCK004
Explanation: The count of requests enqueued and
waiting to obtain a lock (or LKWRD, described by
HCPLKWRD COPY) became negative.
User Response: Examine the dump and the trace
table and try to determine why the count went negative.
Register R4 points to the LKWRD, and LKWDQLEN is
the count field within the LKWRD. Contact your IBM
support personnel.
LCK005
Explanation: The critical process count, VMDCTCRT
in the base VMDBK, became negative. Usually this
count represents the number of locks held by the virtual
machine. (The degree of criticality is usually equal to
the number of locks held.)
Some, but not all, of the possible causes of this abend
are:
v The code that was to decrement VMDCTCRT was
somehow allowed to execute before the code that
was to do the corresponding increment. For example,
if the following sequence is possible:
1. Lock ownership is switched to another VMDBK
2. The other VMDBK is immediately enabled to
begin running on another processor with the lock
3. VMDCTCRT is incremented in the VMDBK that
just was granted the lock.
It is potentially possible for the second processor to
execute the code that releases the lock and
decrements VMDCTCRT before the first processor
increments VMDCTCRT. VMDCTCRT must always
be incremented before it is possible for another
processor to start processing the code that will do the
corresponding decrement.
v VMDCTCRT was incremented on one VMDBK, then
a VMDBK switch occurred before the corresponding
decrement took place. This may often happen on
task threads that switch between a user VMDBK and
the system VMDBK, or switch between VMDBKs in a
single virtual MP complex.
v A task thread did not properly serialize its increment
or decrement of VMDCTCRT, such as by using the
compare-and-swap instruction.
v When attempting to increment VMDCTCRT on other
than the running VMDBK, the wrong VMDBK was
chosen.
User Response: Examine the CP trace table and
storage dump and try to determine why the base
VMDBK changed from zero to a negative value in the
VMDCTCRT field. Register R11 points to the dispatched
VMDBK. The field VMDBASE in the dispatched VMDBK
points to the VMDBK containing VMDCTCRT. Contact
your IBM support personnel.