IBM SC34-7012-01 Server User Manual


 
v Commit failure, where a unit of work has failed during the commit action. The
commit action may be either to commit the changes made by a completed unit
of work, or to commit the successful backout of a unit of work. This failure is
caused by a failure of the SMSVSAM server, which is returned as RLSSERVER
on the CAUSE option and COMMITFAIL or RRCOMMITFAIL on the REASON
option of the INQUIRE UOWDSNFAIL command. (RLSSERVER is also returned
as the WAITCAUSE on an INQUIRE UOW command.)
Commit failures can be retried after the cause of the failure has been corrected.
The retry usually occurs automatically.
Note that INQUIRE UOWDSNFAIL displays information about UOWs that are
currently failed with respect to one or more data sets. The command does not
display information for a unit of work that was in backout-failed or commit-failed
state and is being retried, or for a unit of work that was indoubt and is being
completed. The retry, or the completion of the indoubt unit of work, could fail, in
which case a subsequent INQUIRE UOWDSNFAIL displays the relevant
information.
SHCDS LIST subcommands
A CICS region that has been accessing a data set may not be running at the time
you want to inquire on unit of work failures in readiness for a batch job.
Instead of bringing up such a CICS region just to issue INQUIRE UOWDSNFAIL
commands, you can use the SHCDS LISTDS, LISTSUBSYS, or LISTSUBSYSDS
commands. These commands enable you to find out which CICS regions (if any)
hold retained locks, and to obtain other information about the status of your data
sets with regard to each CICS region. You then know which regions you need to
start in order to resolve the locks. These commands are described in z/OS DFSMS:
Access Method Services for ICF.
The SHCDS LIST commands could also be useful in the unlikely event of a
mismatch between the information that CICS holds about uncommitted changes,
and the information that the VSAM RLS share control data set holds about
retained locks.
Resolving retained locks and preserving data integrity
Unless prevented by time constraints, you are recommended to resolve retained
locks by using the INQUIRE UOWDSNFAIL command and retrying shunted UOWs.
About this task
Procedure
1. Use the INQUIRE UOWDSNFAIL command to find out which failed component has
caused the UOW to have retained locks for this data set.
2. If a unit of work that has been shunted with a CAUSE of DATASET and a
REASON of DELEXITERROR, enable a suitable global user exit program at the
XFCLDEL (logical delete) global user exit point and then issue a SET DSNAME
ACTION(RETRY) command to retry the backout and drive the global user exit.
3. If a unit of work that has been shunted with a CAUSE of CONNECTION, use
the SYSID and NETNAME returned by INQUIRE UOWDSNFAIL to find out what
has caused the indoubt condition and correct the failure, after which automatic
resynchronization should allow the unit of work to complete, either by being
backed out or by committing the changes.
176 CICS TS for z/OS 4.1: Recovery and Restart Guide