Help

 

FCRVWAIT

If you have a task waiting on resource type FCRVWAIT, it means that the task is waiting within VSAM for I/O to take place, or is waiting for a record lock.

A wait on resource type FCRVWAIT occurs when conflicts over shared or exclusive locks are deferred internally by VSAM and not returned as an error condition to CICS. Conflicts that can cause an FCRVWAIT wait are:

  • A task issues a file control READ UPDATE request for a record, for which:

  • Another task already holds an exclusive lock 

  • One or more tasks hold a shared lock. 

  • A task issues a file control READ request with CONSISTENT or REPEATABLE integrity for a record, for which:

  • Another task already holds an exclusive lock. 

  • Another task is waiting for an exclusive lock because one or more tasks may already have a shared lock, or another task has an exclusive lock. 

Waiting on this resource can occur only for files accessed in RLS mode.

The following does not apply to CICS Transaction Server 1.1:

A task could be in an FCRVWAIT state because of a deadlock. If VSAM detects an RLS deadlock condition, it returns a deadlock exception condition to CICS, causing CICS file control to abend the transaction with an AFCW abend code. CICS also writes messages and trace entries that identify the members of the deadlock chain.

VSAM cannot detect a cross-resource deadlock (for example, a deadlock arising from use of RLS and DB2 resources) where another resource manager is involved. A cross-resource deadlock is resolved by VSAM when the timeout period expires, as defined by either the DTIMOUT or FTIMEOUT parameters, and the waiting request is timed out. In this situation, VSAM cannot determine whether the timeout is caused by a cross-resource deadlock, or a timeout caused by another transaction acquiring an RLS lock and not releasing it. In the event of a timeout, CICS writes trace entries and messages to identify the holder of the lock for which a timed-out transaction is waiting. Similarly, a task could be made to wait on another task that has an exclusive or shared lock on a record. If this second task was, itself, waiting for an exclusive lock on a resource for which the first task already has a lock, both tasks would be deadlocked.