Specifying concurrent copy for DUMP requests

On the DFSMSdss DUMP command, you can specify that DFSMSdss is to use the concurrent copy function to process data. To do so, you specify the CONCURRENT keyword, and, optionally, one of several available sub-keywords to indicate the type of concurrent copy to be used and whether DFSMSdss can use other methods of data movement. If you do not specify the CONCURRENT keyword, your DUMP request does not use concurrent copy.

The CONCURRENT keyword applies to all of the data being dumped. You cannot apply this function to a subset of the data being processed.

If you specify the CONCURRENT keyword, DFSMSdss might use a function equivalent to the cache-based concurrent copy, called virtual concurrent copy. During virtual concurrent copy, data is "flashed" or "snapped" from the source location to an intermediate location, and then copied to the target location using standard I/O. The operation is logically complete after the source data is "flashed" or "snapped" to the intermediate location and physically complete after the data is moved to the target media.

If the source volume supports data set FlashCopy®, DFSMSdss uses FlashCopy to provide virtual concurrent copy. If the source volume is a RAMAC Virtual Array (RVA), DFSMSdss uses SnapShot. For more information about virtual concurrent copy, refer to Using concurrent copy.

Attention: Use concurrent copy only during periods of light update activity for the data sets or volumes involved. Performing cache-based concurrent copy operations against many large data sets when there is also heavy update activity (such as reorganizing data sets or initializing the volume the data sets reside on) might result in a shortage of storage, because data is transferred to z/OS® data space storage faster than DFSMSdss can process it. When you use multiple simultaneous concurrent copy tasks to process large, heavily updated data sets, you might also experience long run times and contention for SYS.DATA.SPACE.LATCH.SET. You must ensure that during the concurrent copy operation another system does not reserve volumes that are to be processed. You must also ensure that jobs and address spaces that are to use the concurrent copy are assigned a WLM service class with a high execution velocity. Do not assign a discretionary goal to concurrent copy work. You should spread multiple concurrent copy jobs across as many LPARs as possible and avoid the use of PARALLEL mode in DFSMSdss.

Note:

To help ensure data integrity, do not update the data during concurrent copy initialization.
If a concurrent copy operation fails after signaling that the concurrent copy initialization is complete (and update activity on the data has resumed), you cannot recover the data to the point-in-time at which the concurrent copy operation was started. The data might have been updated while the copy operation was progressing.
VM mini-volumes are supported if you are using RVA devices to the extent that they are supported by IBM® Extended Facilities Product (IXFP) device reporting.
The use of concurrent copy and virtual concurrent copy with the DFSMSdss DUMP command is controlled by the RACF® FACILITY class profile, STGADMIN.ADR.DUMP.CNCURRNT.

For information about specifying CONCURRENT and other DUMP command keywords, refer to DUMP command for DFSMSdss.