Populating the New Structure

After the system has connected all active users to the new structure, one or more systems in the sysplex cooperate to populate the new structure by copying data to it from the old structure. Both the old and the new structure must remain viable and accessible to the systems copying the data during this Copy Phase of the process.

The copy process is similar for both system-managed rebuild and duplexing rebuild. Major differences are noted in the following description of the data copied. The data copied includes:

Cache structures
- Registration of interest in cache data, with the following exceptions.
  Cache structures contain information about users' interest in data items stored in the structure. Users track the validity of their local copies of the cached data items by registering interest in particular data items. Under most circumstances, the rebuild process copies this registration for all entries in the structure, preserving the validity of all entries that are in the users' local caches. However, the rebuild process will not attempt to copy registration data, for any entries, if there is no suitable coupling facility with sufficient storage to contain both the registration data and all other structure data that must be copied, but at least one coupling facility has sufficient storage to copy all the non-registration data.
  
  Not having the registration data copied can have a short-term impact on application performance after the rebuild completes. In this case, the system indicates in the connectors' local cache vectors that all local copies of cached data items are not valid. Users must therefore refresh their local buffers, possibly by reading from the cache structure. Registrations will gradually be reestablished through normal cache reference.
  
  For system-managed duplexing rebuild, the following difference exists: Copying of cache structure registrations is never performed during system-managed duplexing rebuild. Therefore, when switching forward to simplex mode using the secondary cache structure, MVS™ will ensure that all users' local cache vectors are overindicated as not valid (thus all local cache buffers are invalidated), since there will be no valid registration information in the surviving simplex structure when the switchover occurs.
- All directory entries, if registrations are being copied. If registrations are not being copied, then only the directory entries accompanying changed or castout locked entries are copied.
- All changed data (if applicable), with adjunct data (if applicable). Changed data includes entries that are locked for castout. Unchanged data is not copied.
- Castout class and storage class definitions, including the assignment of entries to castout classes and storage classes, and including the storage class statistics for all storage classes.
  For system-managed duplexing rebuild, the following difference exists: Cache structure storage class statistics are not copied from the old structure to the new structure, nor are they duplexed on an ongoing basis between the two structure instances. Rather, each structure instance maintains its own storage class statistics independently. An IXLCACHE request against a duplexed structure to return the storage class statistics will always return only one set of storage class information, that of the primary (or old) structure. An IXLMG request against a duplexed structure, on the other hand, will return two sets of storage class information, one from each of the allocated instances of the structure. This allows monitor programs such as RMF™ to display actual storage class information showing how each of the structures in the duplex pair is being used over time.
  
  When the structure switches from duplex mode to simplex mode, keeping the secondary instance of the structure, there will be a discontinuity in the information returned to the connector by the IXLCACHE request to return storage class statistics. The request at that time will return the set of storage class information from the secondary structure, which is now a simplex structure. The Structure State Change Notification event presented when switching out of Duplex Established can serve as an external notification of this discontinuity.
List structures
- All list entries and associated data, with adjunct data (if applicable). All list entry attributes, such as names, keys, entry IDs, and version numbers, are preserved, as is the ordering of entries on all lists in the structure.
- Lock table entries (if applicable (serialized lists))
- Registered monitoring interest in lists, sublists, and event queues (if applicable), as well as the event queues themselves.
Lock structures
- Lock table entries. Resource status (contention status, global management, resource queues, for example) remains unchanged across the rebuild.
- Record data (if applicable), including the entry IDs associated with the record data.

Once the new structure has been populated with the data from the old structure, and the system determines that the structure is viable, either the old structure can be deallocated and connected users can be notified of the new instance of the structure (for rebuild) or the old and new structure instances remain allocated and connected users enter the Duplex Established phase.