zVM Flashcopy processing using XRC Mirrored volumes

When executing a CP FLASHCOPY process for dasd volumes (Cyl 1 - END), in an XRC mirrored environment, errors occur if the target dasd volume is a XRC Primary volume.

The IBM Storage and VSE Support team provide STF a list of all dasd volumes the customer required for DR. The STF Storage team then divided those volumes into 4 scripts, with each script handling all volumes from 4 different DASD LUs.

When the VSE batch processing starts and at certain intervals within the batch cycle, the VSE Support team runs a Flashcopy process (in the zVM environemnt) that flashes the select VSE volumes (Group A -approx 120 volumes) to non-XRC dasd volumes (Group B - approx 120 dasd volumes). If there is an issue with Batch, the VSE Support would flashback all of the data from the non-XRC volumes to the original source volumes. Example of the REXX exec and error messages are in the case example.

The STF Technical team told us that a new release of XRC was in the works and that it would be available in 2019. In the interim, we put together a FLASHBACK work-around. This entailed allocating 120 additional dasd volumes (Group C - non-XRC). If there was a problem with batch, the VSE support team would then flashcopy the Group B volumes to Group C volumes. The Operations staff would contact STF Storage, so that they can update their XRC Scripts, removing Group A volumes from XRC scripts and adding Group B volumes to the XRC scripts. We had to perform this work-around in early February this year.

Earlier this year, STF notified us that a microcode upgrade may fix this flashcopy issue, allowing us to use XRC Primary volumes as target volumes during flashcopy processing. The STF technical staff upgraded the microcode on their test box and ran tests. They then upgraded the microcode on Secondary box and ran tests. All test were positive, but all of their tests were from zOS(MVS) systems, not zVM systems. They then informed us that we would have to update the LOADPARM bit with FCTOXRCPRIMARY after the microcode upgrade. ZVM system do not use LOADPARM parameters.

From the customer's standpoint, they are vulnerable for disaster recovery from the time of the Group B to Group C flashcopy until the time the STF Storage team complete the XRC script updates and re-synchronized the XRC mirror. This situation last occurred on February 11, 2020, total time 4:22.

Production environment,
zVM 6.4
DS8884 2831-984 s/n 75ZG160