SRDF/A in Z/OS system

Hi there,

So you have 2 DMX's. One RDF group per DMX?  Are you running MSC to co-ordinate the cycle switching between the RDF groups?

Your best and simplest option would be to CLONE the required R2 devices and use the cloned devices in your DR test. That way there is no requirement to do anything with SRDF/A and all your devices remain protected, even when doing a DR test.

Unlike SRDF/S, all devides on an RDF group must be in SRDF/A mode or not. i.e For a given RDF group you can have some devices in SRDF/A mode and others not. So you would need to drop SRDF/A, perform a MOVEPAIR to move the required devices out of the SRDF/A RDF group and into another RDF group. Restart SRDF/A. Now you can do whatever you want with the DR test devices. You can do a MOVEPAIR back into the SRDF/A group with the CEXEMPT flag while SRDF/A remains active.

A potentially simpler implementation for you would be a seperate SRDF/A group for you DR test vols so you only interrupt SRDF/A on the DR test vols. You may then need MSC to keep the SRDF/A groups cycle switching in a consistent manner.

Hope this helps.

A small correction to my previous post... You can set consistency exempt on  devices in an active SRDF/A session in order to move them out of the RDF group without suspending SRDF/A. The Consistency Exempt feature is detailed in the current SRDF Host Component  product guide.

Note that you need current 5773 or 5774 microcode to exploit this feature.

Hi,

thanks for answer.

  I know using Clone on remore DMX is easier to test a DR scenario, but we don't have more disk to plan this.  I think we plan to seperate SRDF/A configuration one for production, one for other volumes.  We just move our remote DMX from one location to a new one and they want to test SRDF/A configuration in DR scenario.  In the same time we study to regroup all of our DMX in a new  primary V-Max  and the same  on DR location.

For microcode we dont have 5773, but we plan it .

have a nice day