FCXCWAIT

If your task is waiting on resource type FCXCWAIT, it means that it cannot get exclusive control of a VSAM control interval at the present time. Another task already has shared or exclusive control of the control interval, so your task is suspended pending the release of that control interval.

For CICS/ESA 4.1 and CICS Transaction Server 1.1, an exclusive control wait on resource type FCXCWAIT occurs within CICS, unlike the similar wait on FCIOWAIT, which occurs within VSAM.

If you find that exclusive control conflicts occur too often in your system, consider changing the programming logic so that applications are less likely to have exclusive control for long periods.

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

The possibility that a task is deadlocked, waiting on itself or another task for release of the control interval, is dealt with in the next section.

Exclusive control deadlock

In non-RLS mode, without some means of avoiding it, a task could wait on itself for exclusive control of a VSAM control interval. If this was allowed to happen, the task would be deadlocked, and neither able to release exclusive control or reacquire it.

Similarly, a task could be made to wait on another task that has exclusive or shared control of a VSAM control interval. If this second task was, itself, waiting for exclusive control of a resource of which the first task has exclusive or shared control, then both tasks would be deadlocked.

CICS, however, provides a mechanism to avoid exclusive control deadlock. If a task is waiting on resource type FCXCWAIT and causing another task to wait (either itself or another task), causing deadlock, the task is abended either with abend code AFCF or AFCG at the time it makes the request for exclusive control.

A task that is abended with abend code AFCF would have been waiting for exclusive control of a VSAM control interval of which another task has exclusive or shared control.

A task that is abended with abend code AFCG would have been waiting for exclusive control of a VSAM control interval of which it has shared control.

See the CICS Messages and Codes manual for more information about these abend codes.

To resolve the problem, you must determine which program caused the potential deadlock. Find out which programs are associated with the abended task, and attempt to find the one in error. It is likely to be the one that provides successive browse and update facilities. When you have found the programs associated with the task, see the next section, "How tasks can become deadlocked waiting for exclusive control".

How tasks can become deadlocked waiting for exclusive control

Tasks can become deadlocked waiting for exclusive control of a CI only when they have shared control of the CI and then attempt to get exclusive control without relinquishing shared control first. This can only occur for VSAM shared resource data sets accessed in non-RLS mode.

For the deadlock to occur, a transaction must first issue a VSAM READ SEQUENTIAL request via EXEC CICS STARTBR. This is a VSAM "shared control" operation. It must then issue some VSAM request requiring exclusive control of the CI without first ending the shared control operation.

The requests that require exclusive control of the CI are:

VSAM READ UPDATE, via EXEC CICS READ UPDATE and, subsequently, EXEC CICS REWRITE. Exclusive control of the CI is not acquired until after the initial read is complete, but it happens automatically after that and the CI is not released until the record has been rewritten.
VSAM WRITE DIRECT, via EXEC CICS WRITE
VSAM WRITE SEQUENTIAL, via EXEC CICS WRITE MASSINSERT

VSAM handles requests requiring exclusive control on a data set that is already being used in shared control mode by queueing them internally. VSAM returns control to CICS, but transactions waiting for exclusive control remain suspended.

Example of code causing an exclusive deadlock

The following sequence of EXEC commands would cause an exclusive control deadlock to occur.

The first command causes shared control to be acquired:

EXEC CICS STARTBR
FILE(myfile)
RIDFLD(rid-area)

This causes no problems. The next command at first acquires shared control while the record is read into "input-area". When an attempt is subsequently made to get exclusive control, deadlock occurs because the task that wants exclusive control is also the task that is preventing it from being acquired.

EXEC CICS READ
  FILE(myfile)
  INTO(input-area)
  RIDFLD(rid-area)
  UPDATE

The following sequence of commands would not cause deadlock to occur, because the transaction relinquishes its shared control of the CI by ending the browse before attempting to get exclusive control of it.

The first command causes shared control to be acquired:

EXEC CICS STARTBR
FILE(myfile)
RIDFLD(rid-area)

The next command causes shared control to be relinquished:

EXEC CICS ENDBR
FILE(myfile)

The next command initially causes shared control to be acquired. The record is read into "input-area", and then exclusive control is acquired in place of shared control.

EXEC CICS READ
  FILE(myfile)
  INTO(input-area)
  RIDFLD(rid-area)
  UPDATE

The transaction now resumes. Exclusive control is relinquished following the next REWRITE or UNLOCK command on file "myfile".