Replay processing is used to deliver replication data that has already been delivered or should have been delivered to the target application. Using replay processing, you can read the sequential (merged) PLOG of an Adabas database and, based on the parameters you specify, send related data to one or more Event Replicator databases.
Replay processing in Event Replicator for Adabas can be run in any of three modes: synchronized, unsynchronized, and replay-only. These modes are described in Understanding Replay Modes.
This document covers the following topics:
In addition, be sure to read about ADARPL prerequisites, described in ADARPL Prerequisites.
Some reasons why you might need to replay replicated records are:
The target application does not process the replicated data correctly or has some sort of failure.
A failure occurs with the message queue tool.
The Event Replicator replication pool fills up. This might occur if the message queue tool is down for a prolonged period.
The Adabas replication pool fills up. This might occur if the Event Replicator Server is down for a prolonged period.
Replication was turned off for a particular file, subscription, or destination for some reason.
You need to send the data to another destination.
In all of these cases, you can use Event Replicator for Adabas's replay processing to redeliver the replication data that was lost.
When you invoke replay processing, you must select a replay mode. Replay processing in Event Replicator for Adabas can be run in any of three modes: synchronized, unsynchronized, and replay-only. All modes replay replicated data reconstructed from protection data in the PLOG. However, they vary in the following ways:
They vary in the steps that must be taken to initiate and run them.
They vary in how they handle new transactions from Adabas while replay processing is occurring.
This section covers the following topics:
Synchronized mode is the recommended mode. During synchronized replay processing, the Event Replicator Server suspends new Adabas transactions. When the replay processing is complete, the new Adabas transactions are automatically synchronized with the replayed data. This mode is only available using the online Adabas Event Replicator Subsystem screens.
The net effect of synchronized mode replay processing is that the target application receives replicated data reconstructed from the PLOG data sets before it receives any new replicated data produced by Adabas. The data is then processed in the chronologically correct sequence.
When running a synchronized replay:
The Event Replicator Server will reactivate all files, subscriptions, and destinations involved in the replay that are inactive.
All new Adabas data for the subscriptions and destinations involved in the replay is held in the Event Replicator replication pool until the replay processing is completed.
If an SLOG has been defined, all new data is written to the SLOG instead. The advantage of using an SLOG is that replay processing makes less use of the replication pool, thus reducing the risk of a replication pool overflow.
When replay processing is complete, the new data held in the replication pool is delogged and processed as usual.
If an SLOG was used, the Event Replicator Server reads the held transactions from the SLOG, processes them as usual, and deletes them. If additional new transactions are received while this delogging process is occurring, they are also written to the SLOG until the delogging process has caught up with the logging process.
If synchronized replay processing fails, the Event Replicator Server will deactivate the files, subscriptions, and destinations involved in the replay that it originally activated.
If an SLOG has not been defined and synchronized replay processing takes so long that the new replication data from Adabas fills up the replication pool, the Event Replicator Server will discard the new data and automatically change the replay processing to replay-only mode.
While replication data is stored in the SLOG file, the Event Replicator Server will not shut down normally (using the ADAEND command). It can be brought down using a HALT command and it can be cancelled or otherwise terminated abnormally. If during the next session, the Event Replicator Server detects data on the SLOG originating from a replay process that took place in the previous session, it deletes this leftover data from the SLOG.
When synchronized replay processing is initiated, a token is assigned to the replay process and can be referenced using the ADARPL batch utility. For information on running the ADARPL utility, read ADARPL Utility: PLOG Replication Replay .
During unsynchronized replay processing, the new Adabas transactions are processed concurrently with the replayed transactions, but no synchronization is performed. This mode is only available through batch runs of the ADARPL utility. For information on running the ADARPL utility, read ADARPL Utility: PLOG Replication Replay .
The net effect of unsynchronized mode replay processing is that the target application receives replicated data reconstructed from the PLOG data sets at the same time and interleaved with any new replicated data produced by Adabas. The data is not processed in the chronologically correct sequence.
When running an unsynchronized replay:
The Event Replicator Server requires that all files, subscriptions, and destinations involved in the replay be active. It will not perform any automatic activation of these resources.
All new Adabas data for the subscriptions and destinations involved in the replay are processed as soon as they are received.
When unsynchronized replay processing is initiated, a token is assigned to the replay process. This token can be used to cancel the replay process, if necessary.
During replay-only processing, replay processing is performed on the replicated transactions in the PLOG, but any new Adabas transactions for the files, subscriptions, and destinations involved in the replay are discarded. This mode is only available using the online Adabas Event Replicator Subsystem screens.
The net effect of replay-only mode replay processing is that the target application receives only replicated data reconstructed from the PLOG data sets. When replay processing is complete, another replay process should be initiated to pick up any new Adabas transactions discarded for the files, subscriptions, and destinations involved in the replay.
When running a replay-only mode replay:
The Event Replicator Server requires that some or all of the files, subscriptions, and destinations involved in the replay must be inactive before replay processing starts so that no replication data from Adabas can be processed using these resources.
When Event Replicator Server starts replay-only mode replay processing, it activates the necessary inactive files, subscriptions, and destinations so that data from the PLOGs only can use them, but blocks and discards all the new data from Adabas for those files, subscriptions, and destinations.
When processing is complete, the Event Replicator Server deactivates the files, subscriptions, and destinations that were inactive when replay-only mode processing was initiated.
When replay-only mode replay processing is initiated, a token is assigned to the replay process and can be referenced using the ADARPL batch utility. For information on running the ADARPL utility, read ADARPL Utility: PLOG Replication Replay .
Before you can initiate replay processing using the Adabas Event Replicator Subsystem, the following prerequisites must be met:
Verify that the correct PLOG is used for the run and that it is a sequential PLOG, not a dual PLOG. You can use the PLOG data set list to help determine which PLOG data sets should be used. For more information, read Reviewing and Managing the PLOG Data Set List.
Verify that the target application can handle duplicate records.
The Adabas database must be active. The Replay Utility will attempt to issue a call to Adabas to obtain the GCB, FCBs, and FDTs from the nucleus.
Prior to initiating a replay process, we recommend that you identify resources involved in the replay process. When you initiate a replay request, specific resources are requested. Data from the PLOG is only processed by the resources involved. If multiple resources of different types (subscriptions, destinations, or files) are requested, data is only replayed for the resources common to all requested resources. This section explains this more fully.
To identify the replay resources actually used by the replay process, you must examine the data flow paths through the Event Replicator server that are initiated by each resource requested for the replay. Each data flow path is defined as a unique one file-one subscription-one destination combination, such that the subscription takes data from the file and delivers it to the destination.
This examination process is best described through a series of examples, using the following resource definitions (where Sx denotes a subscription name, Fx denotes a file number, and Dx denotes a destination name):
S1: F1, F2, D1, D2
Subscription S1 includes processing information (SFILE definitions) for files F1 and F2 to destinations D1 and D2.
S2: F2, F3, D2, D3.
Subscription S2 includes processing information (SFILE definitions) for files F2 and F3 to destinations D2 and D3.
Eight unique data flow paths are identified by these definitions:
F1, S1, D1
F1, S1, D2
F2, S1, D1
F2, S1, D2
F2, S2, D2
F2, S2, D3
F3, S2, D2
F3, S2, D3
The remainder of this section uses these example definitions to describe the data flow paths and ultimate effect on replay processing in four different replay scenarios:
If you only specify one resource in the replay request, the effect of the replay processing is determined by the union of the constituents of all data flow paths going through the one resource.
For example, based on the example definitions described earlier in this section, suppose you specify D2 as the resource for the replay request. In this case, the resources involved in the replay are F1, F2, F3, S1, S2, and D2. The data flow paths are:
F1, S1, D2
F2, S1, D2
F2, S2, D2
F3, S2, D2
Any transactions flowing through these data paths will be replayed.
If you specify multiple resources of one type (destination, subscription, or file) in the replay request, the effect of the replay processing is determined by the union of the constituents of all data flow paths going through any specified resource.
For example, based on the example definitions described earlier in this section, suppose you specify D1 and D3 as the resources for the replay request. In this case, the resources involved in the replay are F1, F2, F3, S1, S2, D1, and D3. The data flow paths are:
F1, S1, D1
F2, S1, D1
F2, S2, D3
F3, S2, D3
Any transactions flowing through these data paths will be replayed.
If you specify multiple resources of different types (destination, subscription, or file) in the replay request, the effect of the replay processing is determined by the union of the constituents of all data flow paths that are common to the data flow paths grouped by type.
For example, based on the example definitions described earlier in this section, suppose you specify S1 and D2 as the resources for the replay request. In this case, the resources involved in the replay are F1, F2, S1, and D2. But the data flow paths used for the replay must be the data flow paths common to both the S1 subscription and the D2 destination.
The data flow paths for the S1 subscription are:
F1, S1, D1
F1, S1, D2
F2, S1, D1
F2, S1, D2
The data flow paths for the D2 destination are:
F1, S1, D2
F2, S1, D2
F2, S2, D2
F3, S2, D2
However, the only data flow paths the S1 subscription and the D2 destination share are:
F1, S1, D2
F2, S1, D2
Any transactions flowing through these two data paths will be replayed.
It is an error to request a replay resource that has no data flow paths in common with other requested resources. When this happens, the entire replay request will be rejected.
For example, based on the example definitions described earlier in this section, suppose you specify S1, D2, and D3 as the resources for the replay request. In this case, the resources involved in the replay should be F1, F2, S1, D2, and D3. But, as you will see below, the D3 data flow paths have nothing in common with the data flow paths for S1 and D2:
The data flow paths for the S1 subscription are:
F1, S1, D1
F1, S1, D2
F2, S1, D1
F2, S1, D2
The data flow paths for the D2 destination are:
F1, S1, D2
F2, S1, D2
F2, S2, D2
F3, S2, D2
The data flow paths for the D3 destination are:
F2, S2, D3
F3, S2, D3
Since the D3 data flow paths are only for subscription S2 and the S1 data flow paths do not include D3, there is no common data flow path for this replay request and the replay request is in error.
Replay processing can be initiated in either of two ways.
First, it can be initiated in a batch job using the ADARPL utility without specifying a replay process token. In this case, an unsynchronized replay is initiated. For complete information on initiating replay processing using the ADARPL utility without a replay process token, read ADARPL Utility: PLOG Replication Replay , using the syntax described in Syntax for Initiating ADARPL Without A Token.
Second, it can be initiated using a replay process token. This method involves a combination of the Adabas Event Replicator Subsystem and a batch ADARPL utility job. In this case, you first use the Adabas Event Replicator Subsystem to generate a synchronized or replay-only replay request. The replay request is assigned a token that you then use in the batch ADARPL utility job. For information on initiating synchronized and replay-only replay requests using the Adabas Event Replicator Subsystem and ADARPL, read Initiating a Replay Request.
You can cancel a replay process if you decide that it is not producing the desired results. However, you will then have to determine how to get the replicated data back in sync with the source database.
To cancel replay processing:
Issue the RPLCLEANUP command. This command will stop replay processing (if it is running when the RPLCLEANUP command is entered) and will clean up any open transactions in the Event Replicator Server that are associated with replay processing. For more information, read RPLCLEANUP Command.
