Number of non-share locks held

Indicates the number of non-share locks (primarily update locks) held. The larger the number of update locks held, the greater the probability of contention between the tasks holding the locks and other tasks accessing the same database.

Issue COMMITs more frequently in update jobs

Task wait status

Indicates whether a task is waiting for access to an area or record

• Tasks that are waiting on locks have an ECB type of 'LMGR Lock'.If you notice a task waiting a long time on one or more locks, review ready modes and database design, especially for contention for OOAK and FOAK records, by examining all tasks exhibiting this behavior for common programs, functions, and database references.
• If overall throughput is constrained, identify the source; for example, CPU or DASD usage.
• If overall throughput is not constrained, identify potential deficiencies in database or application design or implementation; for example, look at the number of locks held by individual programs; determine if tasks contend for OOAK and FOAK records in which case lowering the DEADLOCK DETECTION INTERVAL might improve the situation.

ECB type

Denotes the type of resource being waited on. In the case of area locks and dbkey locks, this statistic will contain the literal 'LMGR ECB'.

Note: in the Performance Monitor this information is listed under the column headings 'First ECB', 'Second ECB', and 'Third ECB'.

Number of shared locks held

Indicates the number of share locks held. Share locks allow transactions other than the owning transaction to read the row, but not to update it. Thus, higher levels of share locks can impede concurrency (and throughput) if they are placed on rows in areas that are heavily accessed.

The number of locks held can be reduced by increasing the COMMIT frequency within the application.

ISO (SQL only)

Indicates the isolation level of the transaction. The isolation level of a transaction defines how long retrieval locks are held.

Ensure that the transaction is running in the appropriate isolation level for the level of data integrity required by the application.

State (SQL only)

Indicates the state of the transaction which defines how the transaction is affecting the data it is processing:

• Read only (RO) specifies that the transaction is reading data but not adding or updating.
• Read write (RW) specifies that the transaction intends to add and update data.

Ensure that the transaction state is appropriate for the type of processing being performed. Transactions that only read data should have a state of RO.

Ratio of global resource lock requests to local lock requests

Indicates the number of times that CA IDMS had to acquire or alter a global lock on an area, page, or record in order to service the indicated number of local lock requests. The larger this ratio, the greater the inter-member contention for resources, since CA IDMS acquires global record and page locks only if contention exists between members.

• Issue COMMITs more frequently in update transactions
• Disperse frequently updated data across more pages within the area
• Increase the size of the area, especially if frequently inserting or deleting data in an area that is more than 70 percent full
• Split the workload between members to minimize inter-member contention for resources

Ratio of the number of global lock waits to the number of global lock requests.

Indicates the number of times that CA IDMS had to wait for a global lock request to complete. This ratio is a measure of one or more of the following types of contention:

• Inter-member contention for transaction resources
• False contention caused by synonyms when hashing to the global lock table
• Contention for operating system resources such as channels

• Use operating system tools to determine the nature of the contention
• Take the actions outlined above to reduce inter-member contention for transaction resources
• Increase the number of lock table entries to reduce false contention

Number of times lock storage overflowed

Indicates the number of times that CA IDMS had to acquire lock storage dynamically in order to satisfy a lock request. The larger this number the more CPU cycles that were expended to satisfy lock requests. Additionally the storage pool may become fragmented since dynamically acquired storage may not always be releasable.

• Examine the overflow details to determine the type of storage overflows that occurred
• Determine the applicable base factor for the type of overflowing storage:
• Session and class storage is based on the number of logical terminal elements (LTERMs) defined for the system.
• Resource and proxy storage is based on the SYSLOCKS system definition parameter
• XES Request storage is based on the maximum number of tasks specified in the system definition.
• Increase the appropriate base factor (the number of LTERMs, SYSLOCKS, or maximum number of tasks) to increase the size of the initial storage allocation, and thus reduce the number of overflows.