gtpd1m21 | Database Reference |
Recovery log support is general in nature and is designed to be extendable
to support recovery of additional resources such as message and tape
processing. User resource managers can be written to allow
application-specific resources to use the recovery log to become part of the
recoverable transaction. The TPF system uses the recovery log with TPF
transaction services processing.
The recovery log permits the TPF system to recover, over a software or
hardware IPL, to the point of failure without compromising the integrity of
the database. Recovery is to a point at which all TPF transaction
services processing is either redone or not redone. Partial update
conditions will not occur.
The recovery log is defined as vertically allocated 4-KB fixed file records
residing on a single logical device type. The log does not span
multiple device types. Each 4-KB record is in the standard TPF
format; that is, each record contains a standard 8-byte header.
The data area of each record is relatively unstructured and contains
information relating to transaction manager and resource manager write
requests.
Writing to the recovery log, which consists of the writing of control
information and data, is done through the use of the WLOGC macro. A
user exit is activated when WLOGC processing has been completed to give users
the opportunity to access the data being written; for example, to write
the information to tape.
Writing associated commit scope log records is a multiple write event, as
the following describes:
- This process is started with a commit transaction. The transaction
manager directs all of the associated resource managers to prepare the data to
be committed.
- Each resource manager then enters WLOGC macros to write its data to the
recovery log.
- Once all of the resource managers (RMs) have completed preparing the data,
the transaction manager (TM) writes a record, using the WLOGC macro, to
indicate that the xa_prepare function has been completed.
- The TM then directs all of the RMs to harden their data (write the data to
the recovery log.)
- When hardening has been completed, each resource manager enters a WLOGC
macro to indicate that the data has been hardened.
Only the log manager (LM) can read from the recovery log.
During restart (after an IPL), the recovery log is used to recall
information to bring the TPF system back to the state it was in before the IPL
occurred. The recovery log is used for any DASD writes or MQSeries
requests that may have been in transition or lost.
The recovery log is defined as processor unique, enabling each processor in
the loosely coupled complex to maintain and recover its own log without regard
to the other processors. The recovery log is a viable entity as long as
its processor is up and running. Under certain conditions, it is
necessary to recover the log to preserve a consistent commit database.
- One of these conditions occurs during the IPL of a processor because of an
outage. In this case, the log is recovered during restart (after the
IPL).
- A second condition occurs when a processor is excluded from the complex
because of a hardware problem or as a nightly collapse procedure. Under
the latter condition, it is expected that the processor will not be
immediately IPLed. Therefore, to preserve a consistent commit database,
the log must be run as part of the processor deactivation process.
- For a condition where a processor is excluded from the complex by way of a
normal cycle down and deactivation, the ZPSMS command with the PROC DEACT
parameters specified permits active ECBs to drain from the system. Once
all activity has been completed, the log is in a state where no transactions
exist that would need to be redone; the log is essentially empty.
Log recovery does not need to be activated. When you IPL a processor
from the deactivate state, the recovery log is reinitialized and any previous
log information is considered to be not valid.
- For a condition where a processor has stopped because of a hardware error
and is not capable of running its own log, it is necessary for another
processor to control the recovery. This process is known as log
takeover.
Log takeover occurs during processing of the ZPSMS command with the PROC FORCE
DEACT x parameters specified.
- A third condition occurs during a catastrophic outage that involves the
entire complex, where the ensuing IPL is of the destructive type (that is, IPL
BYPASS). For this condition, the first processor to IPL successfully is
responsible for recovering its own log and the log for each of the other
processors.