Peer-to-peer remote copy (PPRC) and extended remote copy (XRC)
PPRC and XRC are both 3990-6 hardware solutions that provide data currency to secondary, remote volumes.
Updates made to secondary DASD are kept in time sequence. This ensures that updates are applied consistently across volumes. PPRC and XRC also ensure that updates are applied in time sequence across control units as well. This sequencing offers a very high degree of data integrity across volumes behind different control units.
Because PPRC and XRC are hardware solutions, they are application, and data, independent. The data can be DB2®, VSAM, IMS, or any other type of data. All your vital data on DASD can be duplicated off-site. This reduces the complexity of recovery. These solutions can also make use of redundant array of independent disks (RAID) DASD to deliver the highest levels of data integrity and availability.
PPRC synchronously shadows updates from the primary to the secondary site. This ensures that no data is lost between the data committed on the primary and secondary DASD. The time taken for the synchronous write to the secondary unit has an impact on your application, increasing response time. This additional time (required for each write operation) is approximately equivalent to a DASD fastwrite operation. Because the implementation of PPRC is almost entirely in the 3990-6, you must provide enough capacity for cache and non-volatile storage (NVS) to ensure optimum performance.
XRC is an asynchronous implementation of remote copy. The application updates the primary data as usual, and XRC then passes the updates to the secondary site. The currency of the secondary site lags slightly behind the primary site because of updates in transit. As part of XRC data management, updates to the secondary site are performed in the same sequence as at the primary site. This ensures data integrity across controllers and devices. Because XRC does not wait for updates to be made at the secondary site, the application’s performance is not directly affected. XRC uses cache and non-volatile storage, so you must provide enough capacity to ensure optimum performance.
In the event of a disaster, check the state of all secondary volumes to ensure data consistency against the shadowed log data sets. This ensures that the same sequence of updates is maintained on the secondary volumes as on the primary volumes up to the point of the disaster. Because PPRC and XRC do not require restores or forward recovery of data, your restart procedures on the secondary system may be the same as for a short-term outage at the primary site, such as a power outage.
- CICS® logs and forward recovery logs
- CICS system definition (CSD) data sets, SYSIN data sets, and load libraries
- Recovery control (RECON) and restart data set (RDS) for IMS
- IMS write-ahead data set (WADS) and IMS online log data set (OLDS)
- ACBLIB for IMS
- Boot-strap data set (BSDS), the catalog and the directory for DB2
- DB2 logs
- Any essential non-database volumes
CICS applications can use non-DASD storage for processing data. If your application depends on this type of data, be aware that PPRC and XRC do not handle it.
For more information on PPRC and XRC, see z/OS DFSMS Advanced Copy Services.