Return Code 16 - EXCLUSIVE CONTROL INTERLOCK

CA Datacom/DB Return Codes › Return Codes › Return Code 16 - EXCLUSIVE CONTROL INTERLOCK

Return Code 16 - EXCLUSIVE CONTROL INTERLOCK

Reason:

There has been an exclusive control interlock error. The record you requested for update is being held under exclusive control by another task. An interlock would occur if you were to wait on that task. To break the exclusive control interlock, CA Datacom/DB rejected your request and PRIMARY EXCLUSIVE CONTROL is released for all the records you held under exclusive control so that it could honor the previous request of the other task to update these records. Keep in mind that more than two tasks may be involved in this interlock. The sum total of waiting tasks is examined, if necessary, to determine if an interlock exists.

To assist in debugging, diagnostic information is passed at X'1A' into the Request Area. It consists of a two-byte hexadecimal DBRW-ID followed by an eight-byte job name (the DBRW-ID and job name are those for which this request was attempting to wait).

Action:

If not using transaction backout, re-read with exclusive control all records released by CA Datacom/DB. If using transaction backout, respond in one of the following ways:

Abort the transaction, or
Issue ROLBK to back out to a stable state, then reacquire exclusive control of all needed records.

See the following internal return codes for details. All of the following automatically generate a Master List dump.

Return Code 16 Internal Return Codes

Dec	Hex	M	B	Explanation	User Response
001	01	Y	N	This indicates an interlock that involves a wait for a procedure subtask. In examining the tasks which participate in this interlock, a task was found that is waiting for a subtask in order to run a procedure. This is considered an interlock because CA Datacom does not have enough information to determine if all outstanding procedures that are occupying the subtasks can complete.	In addition to using the general user response information previously given, you can increase the number specified on the tcbs parameter of the PROCEDURE MUF startup option.
002	02	Y	N	This indicates an interlock that involved a wait across the MUFplex. In examining the tasks that participate in this interlock, at least one wait spanned the MUFplex, that is, a task was waiting on a row that a task running on a different Multi-User Facility within the MUFplex owned. If the request that encountered the error was trying to wait on a task across the MUFplex, the diagnostic information includes the Multi-User Facility number being waited upon at X'24' in the Request Area. For performance reasons, interlock detection across the MUFplex is done asynchronously with no locks to serialize all waits across the MUFplex. Examining all tasks that participate in the interlock in a changing system across the MUFplex can result in an interlock detection that would not be true if the entire MUFplex were synchronized.	See the general user response information previously given.
012	0C	Y	N	This is a general interlock indicator. In addition to the general documentation given above, the following can cause an interlock. An interlock can occur when an ADDIT or UPDATE attempts to add a value to a column that is part of a unique key where the key value is under secondary exclusive control through an uncommitted delete, add, or update. Return code 16 (012) is not likely to occur, but it can occur if the Log Area is initialized with a lower TSN (transaction sequence number) than was previously used. To minimize any risk, Log Areas should not be initialized unless necessary (such as a larger or smaller extent or due to I/O errors on logging). Each RESTART report from a Multi-User Facility execution and REPORT AREA=LXX provides the highest transaction sequence number. This number (printed as hex digits) can be provided when executing the INIT AREA=LXX function.	See the general user response information given above.

Dec

Hex

Explanation

User Response

001

This indicates an interlock that involves a wait for a procedure subtask. In examining the tasks
which participate in this interlock,
a task was found that is waiting for
a subtask in order to run a
procedure. This is considered an interlock because CA Datacom
does not have enough information
to determine if all outstanding procedures that are occupying the subtasks can complete.

In addition to using the general user response information previously given, you can increase the number specified on the tcbs parameter of the PROCEDURE MUF startup option.

002

This indicates an interlock that involved a wait across the
MUFplex. In examining the tasks
that participate in this interlock, at least one wait spanned the MUFplex, that is, a task was waiting on a row that a task running on a different Multi-User Facility within the MUFplex owned. If the request that encountered the error was trying to wait on a task across the MUFplex,
the diagnostic information includes
the Multi-User Facility number being waited upon at X'24' in the Request Area.

For performance reasons, interlock detection across the MUFplex is done asynchronously with no locks to serialize all waits across the MUFplex. Examining all tasks that participate
in the interlock in a changing system across the MUFplex can result in an interlock detection that would not be true if the entire MUFplex were synchronized.

See the general user response information previously given.

012

This is a general interlock
indicator. In addition to the general documentation given above, the following can cause an interlock.

An interlock can occur when an
ADDIT or UPDATE attempts to add
a value to a column that is part of
a unique key where the key value
is under secondary exclusive
control through an uncommitted delete, add, or update.

Return code 16 (012) is not likely
to occur, but it can occur if the Log Area is initialized with a lower TSN (transaction sequence number)
than was previously used. To
minimize any risk, Log Areas should not be initialized unless necessary (such as a larger or smaller extent
or due to I/O errors on logging).
Each RESTART report from a Multi-User Facility execution and REPORT AREA=LXX provides the highest transaction sequence
number. This number (printed
as hex digits) can be provided
when executing the INIT AREA=LXX function.

See the general user response information given above.