IBM SC34-7012-01 manual Inquire Dsname, Inquire Uowdsnfail, About this task

About this task

However, it does know about the uncommitted changes that are protected by such locks, and why the changes have not yet been committed successfully. CICS uses this information to help you resolve any retained locks that are preventing you from switching to non-RLS access mode.

INQUIRE DSNAME

You can use the INQUIRE DSNAME command to find out whether the data set has any retained locks or if it is waiting for lost locks recovery by any CICS region.

INQUIRE DSNAME(...) RETLOCKS returns a value of RETAINED if the CICS region has any shunted units of work that have made uncommitted changes to the named data set, and NORETAINED if it does not. (RETLOCKS may return the value NORETAINED while changes are being made or units of work are being retried.) You can use this command to find out whether or not there are any retained locks that you need to resolve before running batch.

The INQUIRE DSNAME(...) LOSTLOCKS command returns:

vRECOVERLOCKS if the CICS region has lost locks recovery work to complete for the named data set. In this case, the RETLOCKS option returns RETAINED (except briefly while recovery work is being carried out, when RETLOCKS could be NORETAINED).

vREMLOSTLOCKS if the CICS region in which the command is issued does not have any lost locks recovery work to complete, but one or more other CICS regions in the sysplex do have. In this case the data set is still in a lost locks condition (but the RETLOCKS option in this CICS returns NORETAINED).

vNOLOSTLOCKS if the data set is not in a lost locks condition. This is the normal case. RETLOCKS could be either RETAINED or NORETAINED.

INQUIRE UOWDSNFAIL

CEMT INQUIRE UOWDSNFAIL DSN(datasetname) can return information about shunted units of work that have failed to commit changes to the named data set. The information includes the resource that caused the failure and, where there can be more than one reason, the reason for the failure. The EXEC CICS INQUIRE UOWDSNFAIL command provides a browse interface, allowing an application program to browse through all the shunted units of work for a data set or a group of data sets.

There are three main categories of failure:

vIndoubt failure, where a communication failure has occurred while a commit participant is in the indoubt state. The cause of an indoubt failure is returned on an INQUIRE UOWDSNFAIL command as CONNECTION. Indoubt failures are retried automatically when the connection is resynchronized.

vBackout failure, where a unit of work that is backing out changes fails during the backout of:

–One or more data sets (which returns a CAUSE of DATASET)

–A number of data sets bound to a failing cache (which returns a CAUSE of

CACHE)

–All the RLS data sets updated in the unit of work when the SMSVSAM server fails (which returns a CAUSE of RLSSERVER with REASON RLSGONE).

Backout failures can be retried after the cause of the failure has been corrected. In some cases, the retry occurs automatically.

Chapter 15. Resolving retained locks on recoverable resources 175