Using the Subscription Logging Facility

The subscription logging facility , also know as the SLOG facility, can be used to ensure that data replicated to specific destinations is not lost if problems occur on those destinations. In order for this to occur, the SLOG facility must be activated for those destinations.

Once activated for a destination and when that destination becomes unavailable, the SLOG facility performs subscription logging by writing the replication data to a Replicator system file called the SLOG system file . This is an Adabas system file on the Event Replicator Server. When the destination is reopened and available, the SLOG facility sends the data it recorded back to the destination, while continuing to record new data to be sent to that destination. Once the destination logging catches up with the current data being replicated, normal replication processing resumes. This means that when all of the data that has been written to the SLOG system file for the destination has been successfully sent to the destination, Event Replicator Server will stop logging data to the SLOG system file for the destination and recommence sending it directly to the destination.

Notes:

  1. Subscription logging is resource intensive and should only be used where absolutely necessary. As an alternative, you should consider using initial state processing to resynchronize replicated data in the event of a queue failure.
  2. If a destination is unavailable for a significant amount of time, a large volume of data can be generated and written to the SLOG system file.
  3. The single point of failure for the SLOG facility is that if the SLOG system file is not large enough to contain the data that must be logged, the SLOG facility fails and data will subsequently be lost.
  4. The SLOG system file is also used for synchronized replication replay.

This document covers the following topics:


Setting Up Subscription Logging

Setting up subscription logging requires the following steps:

Step 1. Calculate the maximum amount of space required.

The installation must make an estimate of the amount of space that will be required for the SLOG system file. The data that is written to the SLOG file are the URB* control blocks and associated data that is written to the messaging system for each transaction. Therefore, the most appropriate mechanism for determining how much data will be written is to monitor the amount of data written to a specific destination during normal processing.

Start of instruction setTo calculate the maximum amount of space, we recommend that you follow the calculation described in these substeps:

  1. Determine the maximum amount of time that a destination may be unavailable. This may be related to maintenance windows, service level agreements, or other factors.

  2. Determine the amount of data that is sent to the destination during its highest level of activity.

  3. Based on the figures from these first substeps 1 and 2 (above), calculate the amount of data that will be written to a destination, assuming maximum outage time during the highest level of activity.

  4. Add a 50% contingency and use the result to calculate the space required in the SLOG system file for the destination.

  5. Repeat substeps 1 through 4 (above) for each destination where the SLOG facility will be activated. If multiple destinations are associated with the same subscription and if the destinations are only written to from that one subscription, only one destination should be included in the calculation as the SLOG facility can optimize the recording of data.

  6. Based on the total space requirements for all destinations for which the SLOG facility will be activated, establish a space requirement for the SLOG system file and verify that the Event Replicator Server is large enough to contain it.

Step 2. Define the SLOG system file.

Using the space calculation from Step 1, use the sample job ADALODSL to define the SLOG system file to the Event Replicator Server. Ensure all blank parameters in the sample job are correctly set. Sample job ADALODSL is supplied in member ADALODSL of the MVSJOBS data set on z/OS, in member ADALODSL.X of the ARFvrs library on z/VSE, and ADALODSL(J) on BS2000.

Step 3. Activate subscription logging for the appropriate destinations.

Review the destination definitions for the destinations for which you want subscription logging activated. Change the value of the DLOG subparameter (in the DESTINATION NAME parameter) to "YES" (DLOG=YES) for all destinations for which you want subscription logging activated. The default for the DLOG parameter is "NO", so subscription logging will only be active on destinations where it has been explicitly requested.

You can also activate subscription logging in these destination definitions using the Allow Logging field using the Adabas Event Replicator Subsystem.

Note:
Consider specifying DAERROR=CLOSE for Adabas destinations defined with DLOG=YES. When an error is encountered and DAERROR=CLOSE, the Adabas transaction will be backed out, the Adabas destination will be closed, and the related replication data will be written to the SLOG system file.

Step 4. Restart the Event Replicator Server.

Restart the Event Replicator Server with the new parameter settings.

Starting Subscription Logging

Once subscription logging has been activated for a destination, it will automatically occur if:

  • You close the destination using the ADADBS REPTOR function. For more information, read ADADBS REPTOR Function.

  • An unrecoverable error occurs on the destination.

  • The destination becomes full.

Stopping Subscription Logging

Once subscription logging is started for a destination, it will automatically stop when the destination becomes available again and all of the logged data is delogged from the SLOG system file to the destination.

Delogging SLOG File Data

Delogging is the process of reading the logged data for a destination in the SLOG system file and sending it to the destination. This will occur automatically for destinations for which subscription logging is activated and for which data has been logged if:

  • You open the destination using the ADADBS REPTOR function. For more information, read ADADBS REPTOR Function.

  • The destination becomes full, on the basis that a full condition is expected to clear itself.

Deleting SLOG System File Data

Data logged is deleted from the SLOG system file when:

  • The data has been delogged and successfully sent to the destination.

  • The destination is deactivated.

  • The data is logged for a destination and the Event Replicator address space has been terminated. When the Event Replicator Server is subsequently restarted and if data exists in the SLOG system file for a destination that no longer exists or for which subscription logging has been deactivated, all SLOG system file data for that destination is deleted.

Note:
In cases where multiple destinations with subscription logging activated are being logged to from a single subscription, the physical data in the SLOG system file will only be deleted when it has been sent to all destinations which experienced a failure. This is due to an optimization in the Event Replicator Server.

Maintaining the SLOG System File

The SLOG system file must be maintained in the same manner as any other system file. The SLOG system file may be deleted, reloaded, saved, restored, refreshed, or reordered. For more information about Adabas system files and utilities, refer to your Adabas Utilities documentation. For complete information about Adabas utility changes specific to the SLOG system file, read Utilities Used with Replication.

We recommend that you start the Event Replicator Server with the ADARUN RPLPARMS parameter set to "NONE" when maintenance on the SLOG system file is required. In particular, ADARUN RPLPARMS=NONE is required if you want to delete or refresh the SLOG file.

Error Conditions for the SLOG Facility

The only error condition expected for the SLOG facility is if the SLOG system file becomes full. When this happens, the destination with the largest number of items on the SLOG system file is identified and deactivated. Note that all SLOG system file data for this destination will be deleted, resulting in data loss for this destination.

In the event of any other error, the SLOG facility will deactivate the destination on which the failure occurred. This will result in all SLOG system file data for that destination being deleted, resulting in data loss for that destination.