z/OS DFSMStvs Planning and Operating Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Avoiding deadlocks

z/OS DFSMStvs Planning and Operating Guide
SC23-6877-00

When applications access data sets in VSAM RLS or DFSMStvs mode, deadlocks can occur within a single instance. They can also arise between two instances of DFSMStvs running under different MVS™ images. VSAM RLS performs deadlock detection and resolution across systems, within its own resources. If it detects a deadlock condition, VSAM RLS fails one of the requests to break the deadlock cycle. DFSMStvs writes messages that identify the members of the deadlock chain.

However, VSAM RLS cannot detect a cross-resource deadlock (for example, a deadlock arising from the use of VSAM RLS and DB2® resources) in which another resource manager is involved. VSAM RLS resolves a cross-resource deadlock when the timeout period expires and the waiting request times out. In this situation, VSAM RLS cannot determine whether the cause of the timeout is a cross-resource deadlock or another unit of recovery acquiring an RLS lock and not releasing it. In the event of a timeout, DFSMStvs writes messages to identify the holder of the lock for which a timed-out unit of recovery is waiting.

Because timeouts are the only way VSAM RLS has for resolving cross-resource deadlocks, you need to specify a timeout value for DFSMStvs requests. You can specify the timeout value in the RLSTMOUT parameter in the IGDSMSxx member of SYS1.PARMLIB, in the JCL, in the ACB, or in the RPL request. If you specify different timeout values, the RPL specification overrides the ACB, which overrides the JCL, which overrides the parmlib member. If you do not specify a timeout value (0), it defaults to no timeout, and requests could wait indefinitely with VSAM RLS unable to resolve the problem.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014