You can maximize XRC data consistency when you ensure that all writes to primary volumes are timestamped. MVS device support code automatically timestamps all writes to XRC volumes.
Nontimestamped writes can exist for primary systems that are not at the required software system level. Nontimestamped writes can also exist for applications on non-MVS systems that bypass the device support code by performing direct I/O. In addition, writes to MVS paging datasets are also done without timestamps.
Care should be taken when adding volumes to an XRC session where nontimestamped writes are done to the volumes. If nontimestamped writes are issued to volumes in a session where timestamped writes are scarce, XRC may experience delays in shadowing these updates to secondary volumes. This delay will cause other coupled sessions to experience the same delays. Such delays can result in excessive accumulation of updates in cache, increased application pacing, and increased risk of Long Busy conditions.
If you plan to shadow volumes containing data sets for which writes are issued without a timestamp, consider shadowing these volumes in a separate, uncoupled data mover. Otherwise, ensure that you have other volumes in the session that will provide a continuous source of timestamps.
XRC copies nontimestamped writes to the secondary volume in the same way that it copies timestamped writes. A specific nontimestamped write that is dependent on other writes on other primary volumes may be applied to the secondary volume in an out-of-order sequence.
Example: If a bank account record is updated with a deposit of $400.00 and then updated with a withdrawal of $300.00, the account record would show an increase of $100.00. Assume that the processing system does not timestamp these data updates. The system applies the deposit update to the account record milliseconds after it applies the withdrawal update from a different volume. Under normal conditions, the volumes at both the primary site and the recovery site receive both updates. It is possible, though, that a disaster at the primary site could destroy the volume that contains the deposit information before the system could add this deposit data to the secondary volume. As a result, the deposit update would not be present on the recovery subsystem. The secondary volume record at the time of recovery would show a decrease of $300.00, with no indication that there is missing data.
Timestamped writes allow XRC to guarantee data consistency. To take advantage of the timestamping feature, ensure that all participating host systems operate with the latest device support code.
If the nontimestamped write has no dependencies on other writes, then it does not jeopardize data integrity. In either case, this condition is temporary and corrects itself during normal operations as XRC applies each set of updates to the secondary volume. However, as indicated previously, nontimestamped writes may cause delays in shadowing all updates for an XRC session. In particular, coupled XRC sessions may cause other XRC sessions to experience the same delays.