z/OS DFSMStvs Planning and Operating Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Using backout logging

z/OS DFSMStvs Planning and Operating Guide
SC23-6877-00

Each instance of DFSMStvs has a private backout log stream in the undo log. This log stream contains both the status of the units of recovery and the backout records that are required to back out changes to a VSAM recoverable data set that are made by units of recovery. Any of the following scenarios can trigger a backout:
  • The application requests a backout.
  • The unit of recovery abnormally ends.
  • The application requests commit, but one of the resource managers detects a problem and responds no during the prepare phase. (An application can use multiple resources managers within a single unit of recovery.)

If DFSMStvs fails or abnormally ends, all in-flight units of recovery that were using DFSMStvs at the time of its failure are backed out. A unit of recovery that is in-flight is one that has made a change to a recoverable resource but has not yet committed or backed out that change. The backouts for these units of recovery are not performed at the time of the failure by the failed DFSMStvs instance. The backouts are performed either at the time of the failure or later by a peer recovery instance of DFSMStvs. You can find more information about DFSMStvs restarts and peer recovery in Diagnosing and recovering from DFSMStvs problems.

In the event of a DFSMStvs failure during the backout, the recovery or restart processing repeats the entire backout. Backout processing tolerates duplicate records and attempts to delete nonexistent record conditions, which arise from the attempt to repeat a backout operation that was previously completed.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014