LENGTH option. If you do, its value is checked against the defined value and you get a LENGERR condition if the values don’t match.
Avoiding transaction deadlocks
Design your applications so as to avoid transaction deadlocks. A deadlock occurs if each of two transactions (for example, A and B) needs exclusive use of some resource (for example, a particular record in a file) that the other already holds.
Transaction A waits for the resource to become available. However, if transaction B isn’t in a position to release it because it, in turn, is waiting on some resource held by A, both are deadlocked and the only way of breaking the deadlock is to cancel one of the transactions, thus releasing its resources.
A transaction may have to wait for a resource for several reasons while executing file control commands: v
Any record that is being modified is held in exclusive control by the access method for the duration of the request. v
If a transaction has modified a record in a recoverable file, CICS locks that record to the transaction even after the request that performed the change has completed. The transaction can continue to access and modify the same record; other transactions must wait until the transaction releases the lock, either by terminating or by issuing a syncpoint request. For more information, see
“Syncpointing” on page 106.
Whether a deadlock actually occurs depends on the relative timing of the acquisition and release of the resources by different concurrent transactions.
Application programs may continue to be used for some time before meeting circumstances that cause a deadlock; so it’s important to recognize and allow for the possibility of deadlock early in the application program design stages.
Here are examples of different types of deadlock: v Two transactions running concurrently are modifying records within a single recoverable file, through the same FCT entry, as follows:
Transaction 1 has acquired the record lock for record 1. Transaction 2 has similarly acquired the record lock for record 2. The transactions are deadlocked because each wants to acquire the lock held by the other. v
Two transactions running concurrently are modifying two recoverable files as follows:
Here the record locks have been acquired on different files as well as different records; however, the deadlock is similar to the first example.
When an application cannot get exclusive control of a record (for example, during a deadlock situation), the OS/400 database facilities wait for the record for a
126
CICS for iSeries Application Programming Guide V5
