Detecting Catalog Resource Contention

Unless resource contention monitoring has been disabled for a resource, the system monitors the following resources for contention:

ALLOCLCK, which is an internal CAS lock that serializes access to CAS allocation task responsible for most catalog allocation events.
SYSIGGV2, which is used to serialize access to associated Catalog records.
SYSZTIOT, which is used to control access to task input/output table resources.
SYSZVVDS, which is used to serialize access to associated VVDS records. The SYSZVVDS reserve, along with the SYSIGGV2 reserve, provide a mechanism to facilitate cross system sharing of catalogs.

The system checks the catalog address space (CAS) for tasks waiting for the resource beyond the specified wait time (by default, 10 minutes). Once a task is identified as waiting beyond the specified wait time, the system writes a SYMREC record to the logrec data set and issues message IEC393I displaying information about the waiting task or tasks. If the task is still waiting after 5 more minutes, this message is repeated. This message will be repeated every 15 minutes thereafter, if nothing changes. If a new hung task is identified or an old hang is resolved, the notification is reset to the new state at the time of the next system check (within 30 seconds).

In addition to notification, the system can also re-drive. When re-drive is active, the first time a service task with an active resource passes the contention threshold, the service task is abended and the request is resubmitted to catalog for processing.

The abend is a 91A-13, which will produce a 246-rsn dump, unless suppressed, and a LOGREC with error code 246 is generated out of module IGG0CLA9 for the service task. When the service task is abended, all resources it currently holds are freed, and the contention caused due to this request is removed.

The original request submitted to catalog is then again assigned to a catalog service task for processing (which could be, but need not be, the same task). The service task will process the request as if it were newly submitted, which leads to three possible results:

The task could again run to contention, which would lead to an new notification and LOGREC after the wait time threshold is past. The only difference in processing is that the re-drive action will not occur on the re-driven request. The second request behaves as if the only action were notification.
The task while re-processing the request could fail before contention occurs. Not all tasks can be re-driven with out error, and additionally may require additional cleanup. For example, the task was in the middle of defining a KSDS and was able to create the DATA portion of the KSDS on the volume prior to being re-driven. The presence of the DATA portion on the volume will cause an error on the re-driven request, and will need to be cleaned up in order to proceed. The re-drive action abends the service task without back-out processing.
The task could run to completion without contention occurring again. This possibility exists if the original cause of the contention was a deadly embrace of multiple resources among catalog service tasks. For example, another service task got resource A and then went after resource B, while a second service task got resource B and then went after resource A. This situation would cause sustainable contention and could be resolved by either service task being re-driven.