Adaptive apply

Adaptive apply processing manages data conflicts that can arise while writing changes to target VSAM data sets.

Adaptive apply is a form of replication in which certain situations that arise while writing changes to the target VSAM data set are not considered to be errors. When encountered, these situations are reported, the current change operation is skipped, and replication continues with the processing of the next change.

Adaptive apply processing is the default apply type for a replication mapping. If you choose to override the default and use standard apply, replication for the subscription stops when an error is encountered.

Example: A record insertion is replicated and a record with a matching key is found that already exists in the target VSAM data set.
  • With standard apply processing, this situation results in an error. In this case, a message is written to the log and the replication process stops and returns an error condition.
  • With adaptive apply processing, this situation does not result in an error. In this case, a message is written to the log, the insert operation for the current change is skipped, and replication continues with the next change.

Adaptive apply is necessary after an immediate stop or failure. Units of recovery (UORs) might be reprocessed for a period of time after restart, when parallel apply was active prior to the immediate stop or failure. The amount of time depends on the amount of parallelism. The time period is the time between the oldest contiguous UOR that is completely processed and the most recent UOR that is processed as part of parallel apply.

When you reprocess a UOR, apply processing can encounter data inconsistencies that generate errors:
  • Missing records
  • Duplicate records
  • Target data set records that contain data that does not match before image data

Conflict handling

In most situations, adaptive apply processing discards changes that generate errors due to data inconsistencies:
  • Insert processing encounters a duplicate record.
  • Delete processing or update processing cannot locate the correct record on the target.
  • Delete processing or update processing does not perform an update when a mismatch occurs between the before image and the existing image in the target record.

If adaptive apply processing encounters a status code for a condition other than one of those listed above, replication stops for the subscription.

Conflict reporting

For standard apply, the first conflict encountered is reported as an error. A summary error message is written to the event log. Hexadecimal dumps of the appropriate records and record images involved in the conflict are written to the diagnostic log.

For adaptive apply, conflicts are reported as informational messages and written to the event log based on the value of the CONFLICTRPTLVL configuration parameter.

When a subscription is restarted after an immediate stop or system failure, adaptive apply is temporarily in effect for all replication mappings within a subscription until all UORs in an unknown state are applied, regardless of the apply type setting for a replication mapping.

Parallel apply and restart processing

To preserve data integrity and maintain the match between source and target data sets, Data Replication for VSAM applies changes to a given record in the correct order during normal operations. However, an immediate stop or a system failure can result in unprocessed changes on the source server that fail to replicate, which can lead to processing the same changes twice.

For example, say that your replication environment is processing six sequential UORs (U1 to U6) when replication stops:

U1

U2

U3

U4

U5

(update RA)

U6

(delete RA)
  ↑ restart point      

In this example, the UORs in bold (U1, U2, U5, and U6) have dependencies because they update the same record. In addition, U5 updates Record A and U6 deletes Record A. U3 is a long UOR, and for this reason Data Replication for VSAM applies the UORs in bold but fails to apply U3 and U4 before replication stops.

Because the apply server sets a new restart time after applying the last contiguous change (U2), processing begins with U3 when the subscription restarts. Consistent with restart processing behavior, adaptive apply is in effect until the target server writes U6, which is the most recent change that completed before replication stopped.

When the target server tries to reprocess U5, the record is missing because U6 already deleted it. Adaptive apply handles the conflict by discarding the update. When the target server reprocesses U6, it also discards the delete.

In summary, adaptive apply processing discards conflicting changes on the assumption that they are a result of previous Data Replication for VSAM processing. Adaptive apply discards other types of changes for similar reasons:

  • Changes to missing records
  • Changes where the before image data does not match the data in the target record