Standardizing the environment

Where possible, design the environment so that it duplicates your primary center configuration as much as possible and adopt procedures to ensure that applicable software and configuration changes are reflected in the secondary center.

Naming conventions

Try to use the same subsystem names, NCF LU names, and XCF destination names. This can save you time in the recovery process and lets you use the same initialization statements that you normally use in the primary center.

Library requirements

The SYS1.PARMLIB requirements to support your secondary-center configuration should be permanently defined on the SYSRES used for the DRP exercise. Also maintain up-to-date IBM Tivoli Workload Scheduler for z/OS software libraries in the secondary center.

Capacity and workload variations

You can direct work to the required MVS™ image by changing the destination specifications on the applicable workstation definitions. If the work can be separated into logical units of processing (for example, IMS™ BMPs, or DB2®), then consider permanently defining these operations to separate workstations. This implementation can provide everyday benefits for processing in the primary center as well. For example, if you define all the IMS BMPs to a processor workstation reserved for that purpose, then you have more power to control the processing of activities, such as:

• Controlled shutdown for scheduled outages to the control region
• Varying the number of BMPs running concurrently depending on the time of day
• Responding to extended recovery facility (XRF) takeovers in cases where z/OS is unaffected
• Handling scheduling of operations during unscheduled outages.

By defining the operations in this way, you can move the entire workload to any destination in your IBM Tivoli Workload Scheduler for z/OS configuration.

JCL considerations

Where possible, standardize JCL requirements for symbolic variables, such as input and SYSOUT classes between the primary and secondary centers. If differences are unavoidable, consider using the IBM Tivoli Workload Scheduler for z/OS JCL variable substitution function to reduce the impact of these changes.

Symbolic variables can be permanently defined in the global table for input classes, SYSOUT classes, and SMS storage classes. Utilization of JCL variable substitution for these items can also prevent JCL changes in your primary center. Refer to Managing the Workload for detailed information.

Automation in the secondary center

The extent of automation in the primary center will, to some degree, determine the environment in the secondary center. Consider these recommendations:

• Automatic job recovery should not be used until the business systems have completed at least one full processing cycle.
• Automatic workload restart and reroute should be switched to manual control.
• The reporting attribute of WTO workstations should be set to manual start and complete if full NetView® services are not available.
• Continue to use ETT if you normally do so, but if your current plan is not extended to the current time, application occurrences added by ETT to the CP fail. When this happens, a message is issued identifying the occurrence. You must then manually add the application to the plan.
• Automation implemented using OPSTAT, EQQUSIN, or EQQUSINT can be handled manually if the automation partner is unavailable.
• In DRP test exercises, the reporting attribute for remotely controlled workstations not involved in the test should be set to nonreporting.