gtpd1m21Database Reference

Recovery Log Support

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

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:

  1. 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.
  2. Each resource manager then enters WLOGC macros to write its data to the recovery log.
  3. 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.
  4. The TM then directs all of the RMs to harden their data (write the data to the recovery log.)
  5. When hardening has been completed, each resource manager enters a WLOGC macro to indicate that the data has been hardened.

Reading from the Recovery Log

Only the log manager (LM) can read from the recovery log.

Restarting 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.

Loosely Coupled Considerations and Log Takeover

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.