Planning for Disaster Recovery Testing

When you back up a Sterling Connect:Direct® system for business continuity testing (also known as "disaster recovery testing or DR testing"), you create a snapshot of the DTF files at one point in time. If the DTF is running when the backup is taken, the captured files may not be in a synchronized known state.

To ensure that you perform a backup at a synchronized point in time to provide a "clean" starting point for the DTF, it is recommended that you put Sterling Connect:Direct in a quiesced, or non-running state when you perform DR backups. Therefore, it is strongly recommended that you set the TCQ global initialization parameter to COLD when you start the DTF at the DR site.

If you do not know at what stage the backup was taken, you may have to deal with the following issues in a recovery situation:

• The TCQ and TCX datasets will probably be out of sync with each other, which will cause a failure when you start Sterling Connect:Direct at a disaster recovery site. The DTF may terminate during initialization.
• If you need the contents of the TCQ to continue, run the DGADTQFX utility before you attempt to start the DTF (see Managing the Transmission Control Queue in the IBM® Sterling Connect:Direct for z/OS® Administration Guide for details). Because the system may not be in a known synchronized state, it is recommended that you set the TCQ initialization parameter to WARM and the QUIESCE initialization parameter to YES. Then you can delete Processes that have already executed before putting the DTF in the "Run" state.
• The NETMAP could also be corrupted if it was dynamically updated when the NETMAP was backed up. If you experience this with your system, unload the NETMAP, delete and redefine it, and then load it from the unloaded source.