Exclusive control of resources
CICS serializes updates to recoverable resources so that if a transaction fails, its changes to those resources can be backed out independently of those made by any other transaction. Consequently, a transaction updating a recoverable resource gets control of that resource until it terminates or indicates that it wants to commit those changes with a SYNCPOINT command. Other transactions requiring the same resource must wait until the first transaction finishes with it.
The primary resources that produce these locking delays are data
sets, DL/I databases, temporary storage, and transient data queues.
The
unit where protection is based is the individual record (key) for
data sets, the program specification block (PSB) for DL/I databases,
and the queue name for temporary storage. For transient data, the
read
end
of the queue is considered a separate resource from the
write
end
(that is, one transaction can read from a queue while another is writing
to it).
To reduce transaction delays from contention for resource ownership, the length of time between the claiming of the resource and its release (the end of the UOW) should be minimized. In particular, conversational transactions should not own a critical resource across a terminal read.
no exclusive control(SERVREQ=NOEXCTL) in the file control table.
This protection scheme can also produce deadlocks as well as delays,
unless specific conventions
are observed. If two transactions update more than one recoverable
resource, they should always
update the resources in the same order. If they each update two data sets,
for example, data set
A
should be updated before data set
B
in all transactions. Similarly, if transactions
update several records in a single data set, they should always do so in
some predictable order (low
key to high, or conversely). You might also consider including the TOKEN
keyword with each READ
UPDATE command. See
The TOKEN option
for information about the TOKEN keyword.
Transient data, temporary storage, and user journals must be included among
such resources.
Locking (enqueuing on) resources in application programs
contains
further information about the extent of resource protection.
It might be appropriate here to note the difference between CICS data sets on a VSAM control interval, and VSAM internal locks on the data set. Because CICS has no information about VSAM enqueue, a SHARE OPTION 4 control interval that is updated simultaneously from batch and CICS can result in, at best, reduced performance and, at worst, an undetectable deadlock situation between batch and CICS. You should avoid such simultaneous updates between batch and CICS . In any case, if a data set is updated by both batch and CICS , CICS is unable to ensure data integrity.