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

IOL008 IOS006
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.
IOL008
Explanation: An attempt was made to destroy a lock
that still had tasks waiting on it, or an attempt was
made to acquire a lock that had been destroyed,
conditions which should never occur.
User Response: Examine the CP trace table and
storage dump to see why this event occurred.
IOL009
Explanation: A request to enqueue a task
(HCPIOLGR) was made without the RDEV lock being
held.
User Response: Examine the calling routine to
determine why it is calling HCPIOLGR without holding
the RDEV lock.
IOL010
Explanation: A task was already enqueued
(RDEVENQ) when another enqueue request was made.
User Response: Examine why the calling routine has
made an additional enqueue request (HCPIOLGR) while
there is an existing enqueue.
IOL017
Explanation: The deferred execution counter,
VMDDFRWK in the VMDBK, became negative.
User Response: Examine the CP trace table and
storage dump to see why the VMDBK in R11 has a
negative value for the VMDDFRWK field. This abend
can be caused by the same things that cause a
52 z/VM: System Messages and Codes — CP
DFR017 abend. See the description of DFR017 for
possible reasons why the abend may have occurred.
IOS002
Explanation: HCPIOS attempted to initiate an I/O
operation while another one was in progress for the
same real device. An I/O condition code 2 was received
in response to a SSCH (Start Subchannel), MSCH
(Modify Subchannel) or HSCH (Halt Subchannel).
User Response: Examine the CP trace table to
analyze other events relating to that subchannel. Look
at the RDEV (pointed to by R8) that HCPIOS uses to
manage the real device. The active IORBK pointer
(RDEVAIOR) may have been reset to zero prior to I/O
completion, causing HCPIOS to prematurely initiate the
next scheduled I/O operation. Another possibility is that
the system did not hold onto a previously initiated
operation.
IOS003
Explanation: HCPIOSRE was called to end a level of
recursion on behalf of an error recovery procedure, but
the recursive IORBK pointer, IORPIOR, contained
zeros. IORPIOR should contain the address of the
IORBK that precedes the last IORBK in the structure.
User Response: Examine the save area of the CP
trace table entries to determine the calling module.
Check R10 to see that it is pointing to a valid IORBK. If
R10 contains the address of the IORBK, storage was
probably overlaid. Otherwise, the requestor probably did
not set the register correctly.
IOS004
Explanation: HCPIOSBS was attempting to transfer
control to the interrupt response address specified in the
IORBK field (IORIRA), but it contained zeros.
User Response: Check R10 to see that it is pointing
to a valid IORBK. If R10 contains the address of an
IORBK, the interrupt response address was probably
destroyed or never set when the request was initiated.
Also examine the status in IORBK.
IOS006
Explanation: HCPIOS attempted to process an
IORBK with the IORXFLG.IROCPSUS bit on, but field
IORSUSND was zero.
User Response: Examine the IORBK, the RDEV, and
the CP trace table to determine what routine obtained
the IORBK. Verify that the routine that built the IORBK
correctly set both the IORSUSND field and the
IORCPSUS bit. If the routine did not, correct that
routine. If it did, attempt to determine how IORSUSND
was set to 0 (or how IORCPSUS was set to 1).