z/OS MVS Programming: Resource Recovery
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Logging data

z/OS MVS Programming: Resource Recovery
SA23-1395-00

RRS hardens information about URs and resource managers in RRS logs. Hardening means storing the information in RRS logs residing on non-volatile external storage that can be accessed during restart after a failure.

RRS hardens information like the following, which a resource manager needs during restart for an incomplete UR:
  • The UR state
  • The name and role of a resource manager with a protected interest in the UR
  • The name of the resource manager's log
  • The resource manager's persistent interest data

Table 1 summarizes the events that cause RRS to harden log information. It highlights the additional logging performed for UR interests that have a presumed nothing protocol. Note that all RRS logging is forced unless Table 1 indicates otherwise.

Table 1. Event Logging Summary
UR State or condition Event Logging
In-state-check to in-prepare The STATE_CHECK exit routines completed successfully. RRS logs information only for presumed nothing interests.
In-prepare to in-commit The overall prepare vote is okay, and the syncpoint is local. RRS logs information for all protected interests.
In-prepare to in-doubt The overall local prepare vote is YES, and the syncpoint is distributed; a resource manager has taken the DSRM or SDSRM role. RRS logs information for all protected interests.
In-doubt to in-backout The Backout_Agent_UR service tells RRS to back out the UR with a log_option of ATR_DEFER_IMPLICIT. RRS logs information only for presumed nothing interests.
In-doubt to in-backout The Backout_Agent_UR service tells RRS to back out the UR with a log_option of ATR_DEFER_EXPLICIT. RRS logs information for all protected interests. If, on restart, the SDSRM always wants in-backout information rather than in-doubt for URs resolved to in-backout, it should always issue Backout_Agent_UR with a log_option of ATR_DEFER_EXPLICIT.
In-doubt to in-backout The Backout_Agent_UR service tells RRS to back out the UR with a log_option of ATR_IMMEDIATE. RRS logs information for all protected interests except the interest of the SDSRM.
In-doubt to in-backout The DISTRIBUTED_SYNCPOINT exit routine tells RRS to back out the UR. RRS logs information only for presumed nothing interests.
In-doubt to in-backout The installation resolves the in-doubt state through a backout command on a panel RRS logs information for all protected interests.
In-doubt to in-commit One of the following occurs:
  • The SDSRM calls the Commit_Agent_UR service to tell RRS to commit the UR.
  • The DISTRIBUTED_SYNCPOINT exit routine tells RRS to commit the UR.
  • The installation resolves the in-doubt state through a commit command on a panel.
RRS logs information for all protected interests.
In-forget to forgotten The Forget_Agent_UR_Interest service with a log_option of ATR_IMMEDIATE tells RRS to forget the UR. The SDSRM's expression of interest is deleted from the log.
In-forget to forgotten The UR completes normally. RRS deletes the log entry for all protected interests. This deletion is an unforced deletion.
Any state RRS detected a heuristic-mixed outcome. RRS logs information for all protected interests at the next state change.
All states, when information has already been logged An RM calls the Set_Persistent_Interest_Data service. RRS immediately logs updated information for all protected interests.
All states except in-flight, in-state-check, in-prepare The Set_Side_Information service indicates heuristic mix. RRS immediately logs information for all protected interests.
All states except in-only-agent The Set_Side_Information service indicates resync-in-progress. RRS logs information for all protected interests at the next state change.
All states except in-flight, in-state-check, in-prepare, in-doubt The SDSRM calls the Forget_Agent_UR_Interest service with a log_option of ATR_IMMEDIATE to tell RRS to forget the UR. The SDSRM's expression of interest is physically deleted from the log.
Any state When UR information has been hardened, and the installation uses a panel to remove a resource manager's interest in a UR. RRS rehardens all protected interests in the UR except the interest being removed.
As Table 1 indicates, RRS hardens data only for protected interests in a UR. Data is not hardened for unprotected interests. Other considerations related to hardening are:
  • RRS retains hardened information until the resource managers interested in the UR indicate, through return codes from exit routines or through service calls, that they have completed their interests in the UR. At that point, RRS deletes the UR information from its RRS logs.
    Note: Because the hardened information for a UR may not be deleted immediately, a resource manager could see on restart an interest in a UR for which the resource manager had completed processing. There is no way for a resource manager to force immediate deletion of hardened information, with one exception: an SDSRM that uses a log-option of ATR_IMMEDIATE forces immediate deletion of hardened information.
  • RRS does not log any information for a UR with only one expression of interest when the resource manager has an ONLY_AGENT exit routine.
  • If a resource manager's exit routine passes a FORGET return code, RRS does not log any information for that interest at any subsequent log points.
  • For a heuristic-mixed outcome or a resync in progress, RRS hardens, or rehardens, the UR state of all protected interests in the UR, including the heuristic-mixed or resync in progress information, at the next state change.

    If a resync in progress occurs before the UR reaches an in-prepare state, RRS defers hardening until the UR reaches the in-prepare state.

  • If DRIVE_COMPLETION or DRIVE_BACKOUT is set, RRS hardens, or rehardens, at the next logging point, the UR state of all protected interests in the UR.
  • When the installation uses a panel to resolve an in-doubt state to in-backout, RRS hardens all protected interests in the UR. In this way, RRS makes sure that, on restart, a distributed syncpoint resource manager sees an in-backout state for a presumed abort interest in a UR. During restart, if a resource manager specifies ATR_RESPOND_CONTINUE in its process interest call for this UR, RRS notifies the resource manager that the installation resolved the in-doubt state to in-backout by invoking the resource manager's BACKOUT exit routine.
  • When the installation uses a panel to remove a resource manager's interest in a UR and RRS had hardened information about the UR, then RRS rehardens the most recent information in the RRS log, minus the interest the installation removed. If the installation removed the last interest in the UR, RRS still rehardens the UR state with no expressions of interest. In this way, RRS makes sure that, on restart, the resource manager does not see the interest that the installation removed.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014