Filter
Top Products
Resynchronization after system or connection failure
Units of work that fail while in an indoubt state remain shunted until the indoubt
state can be resolved following successful resynchronization with the coordinator.
Resynchronization takes place automatically when communications are next
established between subordinate and coordinator. Any decisions held by the
coordinator are passed to the subordinate, and indoubt units of work complete
normally. If a subordinate has meanwhile taken a unilateral decision following the
loss of communication, this decision is compared with that taken by the
coordinator, and messages report any discrepancy.
For an explanation and illustration of the roles played by subordinate and
coordinator CICS regions, and for information about recovery and
resynchronization of distributed units of work generally, see the CICS
Intercommunication Guide.
CICS system log
CICS system log data is written to two MVS system logger log streams, the
primary log stream and secondary log stream, which together form a single logical
log stream.
The system log is the only place where CICS records information for use when
backing out transactions, either dynamically or during emergency restart
processing. CICS automatically connects to its system log stream during
initialization, unless you have specified a journal model definition that defines the
system log as DUMMY (in which case CICS can perform only an initial start).
The integrity of the system log is critical in enabling CICS to perform recovery. If
any of the components involved with the system log—the CICS recovery manager,
the CICS log manager, or the MVS system logger—experience problems with the
system log, it might be impossible for CICS to perform successfully recovery
processing. For more information about errors affecting the system log, see “Effect
of problems with the system log” on page 33.
The CICS System Definition Guide tells you more about CICS system log streams,
and how you can use journal model definitions to map the CICS journal names for
the primary system log stream (DFHLOG) and the secondary system log stream
(DFHSHUNT) to specific log stream names. If you don't specify journal model
definitions, CICS uses default log stream names.
Information recorded on the system log
The information recorded on the system log is sufficient to allow backout of
changes made to recoverable resources by transactions that were running at the
time of failure, and to restore the recoverable part of CICS system tables.
Typically, this includes before-images of database records and after-images of
recoverable parts of CICS tables—for example, transient data cursors or TCTTE
sequence numbers. You cannot use the system log for forward recovery
information, or for terminal control or file control autojournaling.
Your application programs can write user-defined recovery records to the system
log using EXEC CICS WRITE JOURNALNAME commands. Any user-written log
records to support your own recovery processes are made available to global user
exit programs enabled at the XRCINPT exit point.
Chapter 2. Resource recovery in CICS 21