If a DFSMStvs instance or the SMSVSAM server fails, normally, it restarts automatically unless it has been specifically requested not to restart automatically. An operator command, for example, is one way to request a DFSMStvs instance to not start automatically. When DFSMStvs restarts, it collects information about any units of recovery that were in progress at the time of the failure. This information comes from three sources:

• The system logs (undo and shunt logs)
• The lock manager (locks that are held on behalf of a unit of recovery)
• RRS, which indicates the state of the unit of recovery (for example, in-commit, in-doubt, or in-backout)

Based on this information, DFSMStvs determines what action to take on behalf of the unit of recovery:

• If the unit of recovery has locks or log records but is not known to RRS:
  • If a commit record is present in the log, DFSMStvs simply releases the locks; processing on behalf of this unit of recovery is complete.
  • If a commit record is not present in the log, the unit of recovery was in-flight at the time of the failure, and restart processing backs out the unit of recovery.
• If RRS indicates that the unit of recovery was in-backout, then restart processing backs out the unit of recovery.
• If RRS indicates that the unit of recovery was in-commit, DFSMStvs completes commit processing for the unit of recovery.
• If RRS indicates that the unit of recovery was in-doubt, DFSMStvs waits for the in-doubt conditions to be resolved and takes the action indicated by RRS.
• If a unit of recovery has log records that do not include a commit record and for which no locks are held, DFSMStvs assumes there is an error. The locks are used to protect the modified records. This error can occur under either of these circumstances:
  • A data set that has retained locks and shunted log records is deleted .
  • The access method services SHCDS RESETLOCKS command is used.
  Use the access method services SHCDS command to purge the unit of recovery.