Current-plan recovery processing

When IBM Tivoli Workload Scheduler for z/OS suspects that the active current plan is unusable, it automatically carries out recovery processing. IBM Tivoli Workload Scheduler for z/OS uses the alternate current plan or the new-current-plan data set (EQQNCPDS) and the active job-tracking log to create a current plan that is fully up-to-date. Here is a step-by-step description of the current plan recovery process:

  1. The current plan is locked to prevent updates from job-tracking events and dialog users.
  2. The active current plan is erased.
  3. The alternate current plan or new current plan is copied to the active current plan. Indicators in the checkpoint data set determine which of the two are actually used. This is explained further in Current-plan processing at Tivoli Workload Scheduler for z/OS startup.
  4. The identity of the active job-tracking log is obtained from the checkpoint record. Every record of the current JT log is used to update the active current plan.

    If recovery is performed from the new current plan, the current JT log and the JT archive log are used to reapply the events that have occurred since the new current plan was created.

  5. The active current plan is now up-to-date. A current plan backup is performed.
  6. Normal IBM Tivoli Workload Scheduler for z/OS processing starts or continues.

If you are scheduling end-to-end with fault tolerance capabilities, perform the following manual actions to make sure that the Symphony™ file is aligned with the rebuilt current plan:

  1. From OPC dialog select the option 3, DAILY PLANNING. The Producing OPC Daily Plans dialog is displayed.
  2. Then, select option 5, SYMPHONY RENEW.
  3. Submit the symphony renew batch job to create a Symphony file aligned with the Current® Plan.

Current plan recovery is performed for these situations:

If the data space CX file becomes unusable, IBM Tivoli Workload Scheduler for z/OS performs these recovery actions:

  1. The current plan is locked to prevent updates from job-tracking events and dialog users.
  2. The CX data space is deleted.
  3. The CX DASD file is copied to a new data space
  4. The identity of the active job-tracking log is obtained from the checkpoint record. Records in the current JT log are used to update the data space.
  5. The data space file is now up-to-date. A current plan backup is performed.
  6. Normal IBM Tivoli Workload Scheduler for z/OS processing starts or continues.

When IBM Tivoli Workload Scheduler for z/OS performs recovery from the new current plan, the EQQNCXDS file is copied to EQQCXDS, a data space is created, and events are reapplied using the JT archive log and the current JT log. The data space is refreshed to the DASD file during the subsequent current plan backup.

If the CX DASD file becomes unusable, follow the instructions in Recovering from errors on the current-plan-extension data set.