Since you are moving the entire datacenter and all dasd is already replicated, then. Old location: 1. Shut down your existing systems. Old location prefered. 2. Break dasd replications. New location. 3. IPL one system. 4. Start Sysplex using your new datasets. 5. IPL the other systems.
Backout: New location 6. Shut down your systems at new locations. Old Location. 7. IPL one system. 8. Start Sysplex using your old datasets. 9 IPL the other systems When up: 10. Restart replication from scratch for next try. The secondaries will have been updated (access date at a minimum), so restarting a suspended replication would result in bad volumes. On Tue, Feb 14, 2012 at 8:43 AM, Staller, Allan <allan.stal...@kbmg.com> wrote: > It is not clear if you are moving the entire SYSPLEX, or merely one or > more of the members. > > It you are moving the entire SYSPLEX, perhaps a SYSPLEX wide restart is > appropriate. However, even if you are moving one or more members of the > SYSPLEX, why not use the "standard" SYSPLEX facilities to assist in the > move? (IIRC, a parallel sysplex can communicate over about 20 km(??) > without "special" accommodations e.g. GDPS). > > Your original SYSPELX CDS's will be intact, so no action should be > necessary if you need to revert to the original location, just IPL and > go. > I would create new CDS's/policies for the new location. > > HTH, > > <snip> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On > Behalf Of Natasa Savinc > Sent: Tuesday, February 14, 2012 4:11 AM > To: IBM-MAIN@bama.ua.edu > Subject: Changing sysplex hardware > > Hello, > we are moving data center to another location. The data is already there > on DASD, replicated synchronously. We plan to stop the sysplex and IPL > from the replicated data , on new processor. We pretty much answered all > questions so far, except for the sysplex and CF. On new location we have > one new processor, that will in the end replace one of the existing > processors. The configuration (LPAR names) are the same, including CF. > > I would like to verify following scenario: > > 1. For fall-back purpose: We allocate new CFRM couple data sets and > prepare new set of IPL parameters. Old ones will be used if we have to > IPL at old location. > 2. Activate new CDS > 3. Change existing policy - define different HW for the existing CF > 4. Start new policy - first question is - will it report an error or > will it just have pending changes for CF? > 5. Shut down system (sysplex) > 6. IPL on new processor > > Would it be better option to define different name for CF on new > processor, and just add a new CF to the active policy, and in all > preference lists? > </snip> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
