Storage subsystem cache

Concurrent copy, by design, minimizes the amount of cache storage that is used for sidefiles. Under normal circumstances, a concurrent copy session uses less than 0.5 MB of cache. It is very unlikely that using a few simultaneous concurrent copy sessions will significantly affect the hit ratios that you achieve with a cached storage subsystem. It is, however, possible that the storage used by a concurrent copy session could have an effect on hit ratios. This is especially likely in cases where the amount of cache is only barely adequate for normal requirements. In those cases, you should increase the size of the cache regardless of whether or not you use concurrent copy.

The following are several tactics that concurrent copy uses to minimize the amount of utilized cache:

When reading data directly from DASD, the SDM and DFSMSdss inhibit the loading of tracks into the cache.
When the cache sidefile holds no tracks, it occupies no cache space. A sidefile occupies cache storage only when it contains copies of tracks that are saved by the cached storage subsystem during processing of intercepted writes.
The SDM reads and deletes tracks from a cache sidefile as soon as it detects that they are present.

The cached storage subsystem monitors the size of the cache sidefiles that an active concurrent copy sessions uses. In the highly unusual case of a system failure or software problem preventing the SDM from reading tracks, the storage subsystem cancels active concurrent copy sessions when the sidefiles occupy more than half of the cache. The storage subsystem cancels sessions by starting with the session with the largest cache sidefile. This action preserves cache storage for use by sharing systems, but does not affect data integrity. Data is safe because the sidefiles contain only images of tracks before an update was applied. When concurrent copy is active, the subsystem maintains the same level of integrity for update operations that it maintains when concurrent copy is not active.