Using Transaction Logging

Event Replicator for Adabas transaction logging (TLOG) allows you to log transaction data and events occurring within the Event Replicator address space. This information can be used as an audit trail of data that has been processed by the Event Replicator Server and of state change events that occurred during Event Replicator Server operations. In addition, it can be used to assist in the diagnosis of problems when replication does not work as expected.

Transaction logging is optional.

This document covers the following topics:


What Data Can Be Logged?

Two types of replication events can be logged to the TLOG file:

  1. Processing events, which occur as a transaction is processed in each stage of replication processing, or when a user request for a transaction is sent through the input queues to the Event Replicator Server. Examples of user requests are requests for initial-state data and retransmission (resend buffer) requests. When a processing event occurs, an event-type record is written to the TLOG along with the data associated with the event.

  2. State-change events, which occur when something happens within the Event Replicator Server that changes the status of the Event Replicator Server. For example, a state-change event occurs when a destination is closed. When a state-change event occurs, only an event-type record is written to the TLOG.

You can select what data is logged based on transaction logging parameters. These parameters can be stored as global, subscription-specific, or destination-specific parameters in the Replicator system file or they can be specified as initialization parameters, which are read from the DDKARTE statements of the Event Replicator Server startup job.

About the TLOG File

The TLOG file, when defined, resides in the current Adabas command log (CLOG). A new subcode is assigned to data specifically for the TLOG. This enables the TLOG to reuse the proven and reliable command logging infrastructure already in place for Adabas. It also means that you can reuse your existing command log operational procedures to handle TLOG data.

Each TLOG entry contains a URBL record and may be followed by other records, depending on the transaction event being logged. Each record written to the TLOG has only one control block per record; any other control blocks or data related to the same event are written as separate TLOG records. The control blocks must all fit in one CLOG record. There are two exceptions to this:

  • The payload associated with the before and after images of a replicated record can span CLOG records. In this case, as much of the payload as possible is put into the first record following the URBD or input transaction information.

  • Large input requests can span CLOG records.

In both cases, if the payload does not fit, additional payload-type records are written to ensure that all of the payload is available for printing on the TLOG.

Potential Space Problems

The TLOG records are written to the CLOG asynchronously with the processing of transactions by the Event Replicator Server. TLOG records are first written to the Event Replicator replication pool and then written from the pool to the CLOG. Therefore, activating transaction logging will have an impact on both your CLOG usage and your Event Replicator replication pool usage. For example, sometimes TLOG processing may not be able to write to the CLOG from the pool immediately (such as when CLOG rotation occurs). In this case, the TLOG records are stored in the Event Replicator replication pool until they can be logged to the CLOG. Such a situation might cause the Event Replicator replication pool to fill up.

The impact on CLOG usage depends on:

  • The amount of TLOG data written. This is controlled by the transaction events that you have requested be logged and how long that logging has occurred.

  • The amount of data flowing through the Event Replicator Server.

The impact on the Event Replicator replication pool usage depends on:

  • The amount of TLOG data written. This is controlled by the transaction events that you have requested be logged.

  • The amount of data flowing through the Event Replicator Server.

These factors should be considered when allocating the Event Replicator Server replication pool and the CLOG or when determining that their sizes should be increased to accommodate TLOG data collection.

If TLOG processing starts to use more than its defined limit of the Event Replicator replication pool (read about the TLMAX parameter), TLOG processing is suspended and a record is built at the end of the TLOG chain indicating that TLOG records were discarded. A counter is maintained of all the records that are lost. TLOG processing remains suspended until Event Replicator replication pool usage returns to below the level set by the TLRESTART parameter.

If the Event Replicator replication pool becomes full, the Event Replicator Server makes a decision about what resources should be freed up, based on the pool usage. If the TLOG is not using sufficient resources to merit freeing its resources, a replication pool overflow record (URBL) is written with a count of zero (0). If the TLOG is using too much of the replication pool, a decision to free up TLOG resources is made. In this case, a URBL record is written that includes the number of TLOG records that were freed to clear the Event Replicator replication pool overflow condition.

Setting Up Transaction Logging

Start of instruction setTo set up transaction logging:

  1. Create and activate command logging for the Event Replicator address space via the CLOG. For complete information on doing this, refer to your other Adabas documentation.

  2. Optionally, specify which transaction events you want logged, as well as the percentage of the Event Replicator replication pool that should be used (TLMAX parameter) and the replication pool usage level below which TLOG processing can continue when the pool fills up (TLRESTART parameter).

    This step is not necessary as default values are supplied for all TLOG parameters. The default for all transaction events is "0" (no logging); the default for TLMAX is "50" percent, and the default for TLRESTART is "40" percent.

    To specify which transaction events you want logged, use the transaction log parameters (read Transaction Log (TLOG) Settings), the subscription-specific log parameters (STLFILTER, STLINPUT, and STLOUTPUT), and the destination-specific log parameters (DTLASSIGN, DTLCOMP, DTLSLOGREAD, and DTLSLOGWRITE). These parameters can also be specified using fields in the Replicator system file using the Adabas Event Replicator Subsystem.

Starting Transaction Logging

Once you have set up the transaction logging parameters, stop and restart the Event Replicator Server to start transaction logging.

Dynamically Modifying Logging Settings

You can dynamically modify the transaction log levels and transaction parameters you have set using the TLOG operator command. For more information, read TLOG.

Stopping Transaction Logging

To stop transaction logging, dynamically modify the transaction log levels of all transaction events to "0" (no logging). Read Dynamically Modifying Logging Settings.

Printing TLOG Records

To print the TLOG records from an Adabas command log file, use the ADARPP utility, the TLOG print utility. For more information, read ADARPP Utility.