Recovery scenarios associated with CICS and batch job failures

Non-Recoverable files are being replicated using MASSINSERT and a CICS TS failure occurs

In this case, the CICS Transaction Server (CICS TS) address space fails while changes to VSAM data sets are buffered and after the corresponding log records are written.

Data Replication for VSAM cannot detect or correct this failure. A data inconsistency occurs for KSDS and RRDS if the key is written after the failure, because the key is already at the target. For an ESDS, the next record that is written will cause a RBA mismatch.

You might need to reload all non-recoverable data sets after a CICS or batch job failure. You can use comparison tools, such as SuperC, to limit reloads by checking the accuracy of the target data sets compared to the source data sets. For a large number of data sets, reloading non-recoverable data sets might be the best choice to avoid the time that individual comparisons might take.

Non-Recoverable data sets are being replicated when MASSINSERT is not used and a CICS TS failure occurs

In this case, the CICS TS address space fails after changes to VSAM data sets are complete and before the corresponding log records are written.

Data Replication for VSAM cannot detect or correct this failure. A data mismatch is detected when the key is changed, but the key is not available at the target

You might need to reload all non-recoverable data sets after a CICS or batch job failure. You can use comparison tools, such as SuperC, to limit reloads by checking the accuracy of the target data sets compared to the source data sets. For a large number of data sets, reloading non-recoverable data sets might be the best choice to avoid the time that individual comparisons might take.

Recoverable ESDSs are written using MASSINSERT and a CICS TS failure occurs

In this case, the CICS address space is lost while ESDS changes are buffered and after the corresponding log records are written.

The source server will release ESDS inserts to the target server for apply processing in write order and break transactional consistency to maintain the target RBA. At this point, the target data set is corrupted in that it contains records that do not exist in the source and those records cannot be reversed.

At CICS restart, a write_delete record is written. This record notifies Data Replication for VSAM that an insert was replicated to the target that was not actually written to the source VSAM data set. Because VSAM does not support delete operations to an ESDS, the source server will stop replication for the subscription and issue message CECV0106E to the event log.

You need to synchronize the target data set from the source and restart replication after setting the log position of the replication mapping. Set the log position to a time after the reload and before the file is available to be updated.

For additional information about how CICS handles locking, see the related references to topics in the CICS library.

Recoverable non-ESDS data sets are written using MASSINSERT and a CICS TS failure occurs

In this case, the CICS address space is lost while changes that do not include ESDS inserts are buffered and after the corresponding log records are written.

The source server will will not forward uncommitted changes to the target server for apply processing. When CICS restarts, Data Replication for VSAM rolls back and discards the UOR.

Recoverable data sets are written when MASSINSERT is not used and a CICS TS failure occurs

In this case, the CICS address space is lost after data set changes are complete, but before the corresponding log records are written. Data Replication for VSAM handles this case and no user action is required.

At restart, CICS backs out the changes or invokes the logical delete exit for ESDS inserts. For ESDSs, the replication log will contain a a write_update record for a logical delete. Data Replication for VSAM ignores the original UOR and the changes written in backout with the exception of the ESDS update written by the logical delete exit.

CICS VR changes are replicated and a batch job fails

This scenario occurs while changes to VSAM data sets are buffered and after the corresponding log records are written.

Data Replication for VSAM cannot detect or correct this failure. A data mismatch is detected when the key is changed and that change is replicated.

You might need to reload all data sets modified by the batch job. You can use comparison tools, such as SuperC, to limit reloads by checking the accuracy of the target data sets compared to the source data sets. For a large number of data sets, reloading non-recoverable data sets might be the best choice to avoid the time that individual comparisons might take.