Resynchronization

Backup and Recovery › Automatic Recovery › Resynchronization

Resynchronization

What is Resynchronization?

Resynchronization is a process in which information is exchanged between two systems to establish attributes relevant to the two-phase commit process and to complete outstanding distributed transactions following a failure. This chapter focuses on resynchronization between CA IDMS systems.

Note: For information about resynchronization between CICS or RRS and CA IDMS see the CA IDMS System Operations Guide.

When Does It Occur?

Resynchronization between CA IDMS systems occurs at the following times.

When a central version is started, resynchronization is initiated with each known backend system. A backend system is known if it was accessed by a database session since the last time the journal files were formatted. If the started system cannot communicate with one or more of its backend systems, resynchronization with those systems is retried on a periodic basis until communication is reestablished.
When a remote database session is started, resynchronization is initiated with the backend system if it was previously unknown (that is, if this is the first time the backend system has been accessed since the journal files were formatted) or if the backend system has been recycled since resynchronization previously took place between the two systems.
Note: A remote database session is started when an application binds a run unit or connects an SQL session to a remote database. It is also started when a DCUF task establishes a remote dictionary as a default.
When manually driven through a DCMT VARY DISTRIBUTED RESOURCE MANAGER command, resynchronization is attempted with the specified resource manager.

Note: For more information about DCMT and DCUF, see the CA IDMS System Tasks and Operator Commands Guide.

What Does It Entail?

Resynchronization begins with an exchange of startup times and journal timestamps between the two systems. As the name implies, the startup time is the time at which a system was started and is used to detect when a partner system is recycled.

The journal timestamp is assigned by a central version the first time it opens a set of journal files after they have been formatted. It is subsequently used to detect when a partner's journal files have been reformatted since the last time the two systems resynchronized with each other.

If no distributed transactions involving the two systems exist at the time that resynchronization takes place, the two systems simply exchange the above information, update their journal files with new or changed partner information, and record each other as open resource managers.

If distributed transactions involving the two systems do exist at the time of resynchronization, each system compares its partner's current journal timestamp with the one that it had saved previously. If the timestamps are the same, resynchronization proceeds by exchanging information about the incomplete distributed transactions that are pending resynchronization. If the timestamps are not the same, it indicates that one of the following has occurred:

The partner system's journal files have been prematurely formatted.
The partner system has been started with incorrect journal files.
The partner system has been started with an incorrect DCNAME parameter.

Any of these conditions result in a resynchronization failure.

Responding to Resynchronization Failures

If resynchronization detects a journal stamp mismatch with a system for which incomplete distributed transactions exist, resynchronization cannot complete. When this occurs, messages are displayed that show the old and new journal stamps and the incomplete distributed transactions that are impacted by the mismatch. The operator is prompted as to what action should be taken. The following example shows the messages that are displayed as a result of a mismatch in SYSTEM74's journal stamps as they are known to SYSTEM73.

DC329021 V73 T23 Journal stamp mismatch for SYSTEM74::DSI_SRV *OLD
2002-12-14-07.20.36.376737
DC329021 V73 T23 Journal stamp mismatch for SYSTEM74::DSI_SRV *NEW
2003-01-30-08.07.42.278334
DC329022 V73 T23 RM Name           Dtrid                      Branch
           State
DC329023 V73 T23 SYSTEM74::DSI_SRV SYSTEM74::01650D6EDFB1AB93-
01650D6A79F31E50 InDoubt
DC329024 V73 REPLY 01 T23 Reply with resynchronization action for
SYSTEM74::DSI_SRV (Ignore,Defer):

Before replying to message DC329024, the cause of the mismatch should be determined. The appropriate response should then be made as outlined in the following table. Until a response is made to the DC329024 message, no database access is permitted with the identified resource manager. Any task attempting such access waits until a response has been made or its wait time is exceeded.

Reply	Meaning and Considerations
IGNORE	This reply specifies that resynchronization with the resource manager should continue. The distributed transactions listed in the preceding DC329023 messages require manual completion. IGNORE is appropriate if the partner system's journal files have been prematurely formatted. In this case, the only way to complete the affected transactions is to do so manually, since the journal entries required to complete the transactions automatically are no longer available on the partner system's journal files. For guidance on how to manually complete the transactions, see "Completing Transactions Manually".
DEFER	This reply specifies that resynchronization with the resource manager should be postponed until a later time. Database access with the identified resource manager is disallowed until resynchronization has completed successfully. DEFER is appropriate if the mismatch can be corrected by recycling one or the other system. Perhaps one of the systems was started with incorrect journal files or the partner system was started with an incorrect DCNAME parameter. After replying DEFER, the system in error should be shutdown and restarted correctly. It may then be necessary to initiate resynchronization using a DCMT VARY DISTRIBUTED RESOURCE MANAGER command.

Meaning and Considerations

IGNORE

This reply specifies that resynchronization with the resource manager should continue. The distributed transactions listed in the preceding DC329023 messages require manual completion.

IGNORE is appropriate if the partner system's journal files have been prematurely formatted. In this case, the only way to complete the affected transactions is to do so manually, since the journal entries required to complete the transactions automatically are no longer available on the partner system's journal files.

For guidance on how to manually complete the transactions, see "Completing Transactions Manually".

DEFER

This reply specifies that resynchronization with the resource manager should be postponed until a later time. Database access with the identified resource manager is disallowed until resynchronization has completed successfully.

DEFER is appropriate if the mismatch can be corrected by recycling one or the other system. Perhaps one of the systems was started with incorrect journal files or the partner system was started with an incorrect DCNAME parameter.

After replying DEFER, the system in error should be shutdown and restarted correctly. It may then be necessary to initiate resynchronization using a DCMT VARY DISTRIBUTED RESOURCE MANAGER command.