XRC operational considerations

This topic addresses physical and operational limitations for XRC, including limits on the number of active volumes and sessions, and volume format restrictions.

The following limitations apply to XRC operations:

Each volume may be an XRC primary in only one session. Each secondary volume can belong to only one XRC volume pair. However, a secondary volume in one XRC session may be a primary volume in another session. A volume cannot be both primary and secondary within the same session.
Each logical storage subsystem (LSS) in an Enterprise Storage Server® (ESS) storage subsystem can support up to 64 XRC sessions. This session limit is a combination of XRC and concurrent copy sessions. The 3990 Storage Control supports up to four XRC sessions per SSID. Each connected MVS system can manage a unique set of volumes behind the storage subsystem.
You can define a maximum of 256 volumes for each LSS in an ESS storage subsystem. The 3990 Storage Control supports up to 128 volumes.
Each XRC session can support a maximum of 80 storage control sessions. However, the practical limit, for a session with a full complement of buffers, is 40 storage control sessions. This limit is further reduced for storage control sessions that continuously handle very high write rates or MB/sec rates, such as those associated with data base logs, or LOGPLUS volumes (which receive system logger streams). These kinds of storage control sessions should be balanced in a ratio of not more than 1:3 with lower activity storage control sessions within an XRC session.
All volumes that are part of XRC copy operations must conform to the following volume format, track, and access method restrictions, to ensure data integrity:
- Volumes must have a standard format for record zero (R0). Volumes with R0 data lengths longer than eight bytes can cause a track format error to remain undetected when the storage control formats the track in cache.
- You cannot assign alternate tracks within the user area. User data can be overlaid if you assign a user track on the primary address as an alternate track for a secondary address.
- All storage control Define Extent commands must specify normal access authorization mode. Data written to an XRC primary device while the storage control is in diagnostic or device support mode is not copied to the XRC secondary volume. It is therefore important to remove volumes from the XRC session before running a utility program like ICKDSF.
XADDPAIRed primary volumes can remain offline when you issue the XSTART command for restart or the XADDPAIR command for suspended pairs. Utility volumes and secondary volumes must be online when you issue the XADDPAIR command. The system applications must have a common time reference.
Ensure that only the system data mover can update XRC secondary volumes. Do not allow non-XRC applications to update XRC secondary volumes. Non-XRC applications may read from secondary volumes, but to avoid potential data integrity exposures, you must prevent operations from writing to XRC secondary volumes.
Assign the secondary volume a different volume serial number than the primary system volume. This will allow both volumes to be online to the system that contains the system data mover. The XRECOVER command changes the secondary volume serial number to that of the primary system volume as part of the recovery operation. If you plan to read from secondary volumes during normal copy operations, either use a different catalog or refer to the data sets by explicit volume serial numbers.
The DFSMS address space must already be active by the time the XRC address space becomes active. To obtain accurate System Management Facilities (SMF) accounting, the DFSMS address space must remain active for the duration of the XRC session, as XRC and DFSMS both write SMF records. The system data mover writes SMF type 42 subtype 11 records.
You may need to build a channel command word (CCW) chain to correct the lack of timestamping in stand-alone programs and in operating systems that do not support timestamping (bypass start I/O drivers).
For VM Systems: XRC can be used to mirror VM application system volumes defined either as unsupported or mini disks. The data mover can run either on a separate MVS LPAR, or on an MVS guest running on the same or different VM system. If an MVS guest system is used, the volumes must be defined as unsupported to the host VM system.
If applications run on a native VM system, writes will not be timestamped. See Understanding the importance of timestamped writes for more information. MVS and Linux operating systems do timestamp writes, even when run as guests under VM

For additional information about secondary volumes, refer to Establishing XRC secondary volumes. For additional information about SMF type 42 records, refer to XRC information in SMF type 42 records.