You should probably *not* use the DSN/VOL parameters for normal production policies. By default the system will find and use the active CFRM couple data set. But whenever you need to put a policy into *another* couple data set, that's where the parameters come into play. You only need to put the policy in the primary couple data set; it will get copied into the alternate data set at IPL time.
The suggestion to create and mirror--but not use!--the DR couple data set makes sense in order to test out both methods. I never thought of doing that to see how things have changed in recent years. However, I would caution against depending on this practice for the long term unless you also implement a solid procedure that *always* duplicates *every* policy change into the DR couple data set. Otherwise you will IPL some day in DR mode and find that some structure(s) are missing or hopelessly out of date and not usable. Also keep in mind that there is no way (that I know of) to determine in DR mode which of multiple policies was the active one at mirror-break time. I prefer to (re)create a policy using the last updated one in the library that holds all the policy build jobs. Work out a practice that you're comfortable with and avoids the most likely operational errors--such as forgetting to make the same update in two different places. Now *that's* a recipe for disaster. . . JO.Skip Robinson Southern California Edison Company SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] IBM Mainframe Discussion List <[email protected]> wrote on 03/16/2006 05:09:10 AM: > Now the pieces make sense. I have made changes to our live CFRM policy for > so long I did not even know you could code the CFRM DSN in the IXCMIAPU > utility. I had always let it default in the past. > > I imagine I must run it twice for the Primary/Alternate CFRM DSN. > > > > Thanks you very much everyone for the assistance, hopefully good news come > Monday. > > > On Wed, 15 Mar 2006 15:47:57 -0800, Skip Robinson > <[EMAIL PROTECTED]> wrote: > > >When you create/reformat the CFRM couple data set, there is no CFRM > >policy. It must be (re)created from a driver system before the first DR > >IPL. (You could kludge it with multiple IPLs of the DR system, but you > >really don't want to go there.) > > > >On the driver system, (re)create the CFRM policy you want to use--with the > >DR CFs defined and included in all structure PREFLISTs--and explicitly > >point to the new CFRM data set including DSN and VOL. Note: if you don't > >include DSN and VOL, the policy will land in the CFRM couple data set of > >the driver system; no good for the DR system. The new CFRM couple data set > >will now contain only one policy--the one you just (re)created. > > > >At the first IPL of the DR system, there will not be any active policy, so > >you need to name it in the COUPLExx member of PARMLIB that you IPL with: > > > >COUPLE > > SYSPLEX(xxx) > > PCOUPLE(x1) > > ACOUPLE(x2) > > CLEANUP(nn) > > INTERVAL(nn) > > --> CFRMPOL(new-policy) /* CFRM POLICY TO ACTIVATE IF NONE FOUND */ > > > >The CFRMPOL parameter tells the system which policy to activate if there > >is none already active at IPL. This is where you name the policy you > >(re)created from the driver system above. > > > >All other couple data sets, if mirrored, will contain the data they had > >when mirroring was broken. > > > >. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
