Backup and Recovery › Distributed Transaction Recovery Considerations

Distributed Transaction Recovery Considerations

Recovery is Automatic

The primary responsibility for effecting recovery of distributed transactions lies with warmstart and resynchronization. Consequently, manual intervention should almost never be required provided that correct operating procedures are followed.

System Interdependence

The one important consideration when dealing with distributed transaction recovery is that systems are no longer independent with respect to recovery. Information on a coordinator's journal files might be needed to complete the recovery process for a participant.

Restarting Failed Systems

When restarting a failed central version, it is advisable to restart it on the same logical operating system image as the one on which it abnormally terminated. This ensures that the restarted system can access (and be accessed by) the same systems with which it was able to communicate prior to the abnormal termination regardless of the intersystem access methods available for use. If the restarted system cannot communicate with another system, it is not able to resynchronize with that system. This may leave incomplete transactions holding locks that prevent access to portions of the database. Resynchronization will eventually complete these transactions when the necessary intersystem communications are re-established.

Completing Transactions Manually In rare circumstances following a resynchronization failure, it may be necessary to complete a distributed transaction manually. CA IDMS provides two ways to do this: either by using DCMT commands or through facilities provided by the manual recovery utilities. Only transactions that are pending resynchronization should be completed manually. This restriction is enforced if using the DCMT commands.

Completing InDoubt Transactions

Regardless of how it is done, when manually completing a transaction whose state is InDoubt, you must specify whether to commit or back out the transaction's changes. You should research the situation carefully before taking any action. If you make the wrong decision, the distributed transaction will have a mixed outcome, meaning that some of its changes will be committed while others will be backed out.

The following sources of information might be helpful in determining the correct action to take:

• The output from a DCMT DISPLAY DISTRIBUTED TRANSACTION command. This will indicate what system is acting as the coordinator for the transaction and can be used if the transaction is still active within the participant. Similar information can be obtained from the detailed reports produced by the PRINT JOURNAL or FIX ARCHIVE utilities.
• Facilities provided by the coordinator for determining the outcome of a transaction.
  • If the coordinator is a CA IDMS system, its journal files will contain a DCOM record for the transaction if its changes should be committed. Use the PRINT JOURNAL summary report to see all incomplete distributed transactions or J-Report 8 to see a list of all distributed checkpoints. (Before generating either report, be sure to offload and include all journal files created since the point of failure.) If there is no DCOM entry for the transaction, then the transaction's changes should be backed out.
  • If the coordinator is RRS, use the RRS ISPF panels to determine the outcome of the transaction. For more information about RRS panels, see the IBM guide MVS Programming: Resource Recovery.
  • If the coordinator is CICS, examine its LOG file or use CEMT commands to determine the outcome of the transaction.