Filter
Top Products
On receiving a request to perform the first phase of a two-phase commit, the
resource manager is expected to get into a state where recoverable changes made
since the last syncpoint can be either committed or backed out on demand, even if
there is an intervening system failure. For example, buffer contents must be moved
to nonvolatile storage. If the resource manager is unable to get into this state, the
exit program should return ‘UERFBACK’ in register 15, to request backout.
Normally, it should return ‘UERFPREP’, to indicate a successful phase 1 of a
2-phase commit.
On receiving a request to wait (indicating that CICS is in-doubt about the outcome
of the UOW), the resource manager should free any task-related resources, such
as the thread. However, it should maintain any locks held by the UOW, and record
that the UOW is in-doubt. See “Enabling for specific invocation-types” on page 303.
On receiving a request to perform the second phase of a two-phase commit, or a
request to back out, the resource manager should take the corresponding
irreversible step, and have the exit program send the syncpoint manager a return
code: either ‘UERFDONE’, meaning that the commit or abend process is complete;
or ‘UERFHOLD’, meaning that the commit or abend must be resolved later. These
return code constants are available to you when you code the macro DFHUEXIT
TYPE=RM in your exit program.
If a resource manager cannot understand a call, it should not change the contents
of the caller’s register 15 before returning to the caller, because it cannot anticipate
how the caller will interpret the change.
Resynchronization
If a failure occurs between returning from the exit after performing phase 1 of a
2-phase commit and the subsequent phase 2 or back out call, the resource
manager must be ready, on restart, to discover the state of the unit of recovery, and
to act accordingly. For programming information about restart resynchronization
using the EXEC CICS RESYNC command, see RESYNC ENTRYNAME, in the
CICS System Programming Reference manual.
If CICS is in-doubt about a unit of work, it sends the exit program a request to wait
(UERTWAIT). When the status of the in-doubt UOW is resolved, CICS initiates a
resynchronization task, to inform the exit program of the outcome of the unit of
work.
Information about in-doubt units of work is retained across both warm and cold
starts of CICS. CICS initialization and keypoint management routines recover from
the system log all information associating resource managers with outstanding units
of recovery, which are resolved automatically when CICS reconnects to the
resource managers concerned.
Coding a program to be invoked by the CICS task manager
If your exit program sets the task manager bit in the schedule flag word, it is
invoked at end-of-task. If you specify TASKSTART on the EXEC CICS ENABLE
command for the TRUE, it is invoked at start-of-task, and (providing it does not
unset the task manager bit), at end-of-task too. To determine whether a particular
invocation is at start- or end-of-task, you can examine the CICS task manager
parameters described in “CICS task manager parameters” on page 282. Typically,
your program shows interest in task manager events if it needs to save task-related
information, such as performance or accounting data, before the task ends.
Chapter 2. Task-related user exit programs 297