Resynchronization and Recovery Considerations

TWS Automation combines the capabilities of two different subsystems, TWS and SA z/OS, which may reside over several systems.

As a result, a failure or a scheduled interruption of services with one of the subsystems, processors, or telecommunications facilities may occur and prevent TWS Automation from processing operations. Further complications arise by shifting work load across multiple system images, either for scheduled workload balancing or as part of a recovery situation.

In such a case, a loss of synchronization can occur between the TWS schedule and the TWS Automation components in NetView. When this happens, you may need a manual process to examine the TWS schedule, to ensure that TWS Automation in NetView is performing actions as required and, in some cases, to resynchronize TWS and TWS Automation.

During a loss of contact or a failure with either TWS or NetView, TWS Automation’s facilities invoke and restore the environment as it was before the failure so that event scheduling can pick up where it left off. This results in a satisfactory resolution and manual resynchronization is not required. See Automated Recovery Functions for additional information.

Generally, the longer the outage, the more likely that resynchronization is required. This depends on the number of scheduled events that are not processed. A long outage during the day may have a smaller synchronization impact than a shorter outage during a period when many online facilities are started or shut down.