Incremental FlaschCopy

Incremental FlashCopy® provides the capability to refresh a volume in a FlashCopy relationship and reduce background copy time when only a subset of data has changed. When INCREMENTAL(YES) or INCREMENTAL(YTW) is specified in a FlashCopy Establish request, the relationship between the source and target volumes is maintained (persists) after the background copy completes, and read/write operations are allowed on the source volume. The difference between specifying INCREMENTAL(YES) or INCREMENTAL(YTW) is whether the target volume is write inhibited. If you specify INCREMENTAL(YES), the FlashCopy target is write-inhibited while the incremental relationship is active. Any attempt to write to the device during this period will be failed by the hardware and surfaced as an I/O error, an error from the access method, or both. Change recording begins, in which a control bitmap is created for each volume to track changes since the previous FlashCopy was taken. When a subsequent FlashCopy establish specifying the incremental option is issued, only the data that has changed since the last incremental request is copied to the target.

As an example, let us say we have established a FlashCopy relationship with volume A as the source and volume B as the target, specifying INCREMENTAL(YES). A background copy of volume A is made on volume and, the ESS creates a control bitmap to record subsequent changes. Figure 1 shows how change recording would have volumes A and B in agreement at completion of the FlashCopy operation.

Figure 1. Example of Initial FlashCopy Results

Sometime after the initial FlashCopy operation completes, tracks A1, A3, A4 and A8 are rewritten. The change recording in Figure 2 is updated to reflect this.

Figure 2. Example of Volume Disagreement

A second FlashCopy establish request is issued with the COPY and INCREMENTAL options, resulting in an update only to tracks B1, B3, B4, and B8, restoring agreement between volumes A and B.

Figure 3. Example of Incremental Update

• When an Incremental FlashCopy request includes the COPY option, and a subsequent Incremental FlashCopy is issued before the first copy is complete, then the incremental updates include those tracks that have been updated since the first copy was made, in addition to those tracks that had not yet been copied when the subsequent request was issued.
• An Incremental FlashCopy relationship cannot be converted to a non-incremental relationship. It must be withdrawn before a new non-incremental relationship can be established.
• When an incremental relationship is withdrawn, any source updates that are pending (since the last increment was applied) are not copied. The withdraw occurs immediately, even if the initial background copy has not completed, or the copy of tracks from the last increment has not completed. FCQUERY cannot show the status of either the initial background copy or an increment copy.

Incremental FlashCopy is supported only for full volumes. The normal FlashCopy restrictions apply to the target tracks of an incremental relationship.

Incremental FlashCopy Versions

When the software and microcode requirements are met, Incremental FlashCopy requests result in Incremental FlashCopy Version 2 (V2), which allows a volume to have more than one incremental relationship. With Incremental FlashCopy Version 1 (V1), a FlashCopy source can have only one incremental target.

FCQUERY requests display the version of Incremental FlashCopy with the value for CR (change recording):

N

The FlashCopy establish was done without change recording.

Y

The FlashCopy establish was done with Version 1 change recording.

2

The FlashCopy establish was done with Version 2 change recording. The source is able to have multiple incremental FlashCopy relationships.

In the following example, the value for CR is 2, indicating Version 2.

FCQUERY Relationship 1                                                   
DEVN SSID LSS CCA  CU     SERIAL       ACT    MAX XC PC CC RV SE  SEQNUM 
0F40 6809  09  00 2107 0000000BDL21      1  10353  N  N  N  N NN 00000000
RELATIONSHIP DETAIL STARTING TRACK: 00000000                             
DEVICE LONG BUSY FOR CG: NO  WRITE INHIBITED: NO                         
---------------------------------------------------                      
  PARTNER    SOURCE   TARGET   S F C C P  C  T S F P                     
LSS CCA SSID START    START    O V O A R  R  W E S M                     
--- --- ---- -------- -------- - - - - - - - - - -                      
 09  01 6809 00000000 00000000 Y Y Y Y Y  2  Y N N N                       
     NO. OF TRACKS: 00004137  TRACKS TO COPY: 000038AF                   
     ESTABL: 2013/03/13 18:20:40  LAST INCR:  2013/03/13 18:20:40        
FCQUERY COMMAND COMPLETED FOR DEVICE 0F40, COMPLETION CODE: 00           
***    

You can cause the system to revert to Incremental FlashCopy V1 by specifying MULTINCRFLC=NO in the DEVSUPxx member of parmlib.

For more information, refer to DEVSUPxx in z/OS MVS Initialization and Tuning Reference.