There are two sides to the sysplex coin: one lives on DASD, the other lives in the CF. As long as DASD is fully replicated, the newly IPLed sysplex member(s) should look exactly like the old.
CF is another matter. In the CFRM policy, each CF is identified by a unique combination of properties: 1. NAME 2. TYPE (model) 3. SEQUENCE (serial number) 4. PARTITION (number) NAME is used throughout the policy to specify structure location. TYPE, SEQUENCE, and PARTITION are used at XCF initialization to identify the hardware to be used for CF structures associated with NAME. If all four properties are different in the new location, the easiest migration path is to create--today--a CFRM policy that includes the new CF in addition to the old CF(s). Include the new NAME in all structure PREFLISTs. XCF in the old location will not be flummoxed that the new CF is unreachable. Likewise in the new location XCF will survive without access to the old CF(s). In this way you can IPL into the mirrored DASD complex with little disruption. Since you have the same CFRM policy throughout, fallback should be as simple as IPLing in the old location. Caveat: be absolutely sure that you're happy with your new home before allowing production updates to occur. Consider that replicating updates back to the old location is essentially a lost cause. Check everything out as thoroughly as possible while users are locked out. Once you let them out on the range, you'll never get them back in the barn. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Mike Schwab <mike.a.sch...@gmail.com> To: IBM-MAIN@bama.ua.edu Date: 02/14/2012 02:09 PM Subject: Re: Changing sysplex hardware Sent by: IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> Resync after the secondary volume is updated? If the mirroring software supports that, it would save a lot of retransmitting. I am fairly sure the ESS F20 and 800 PPRC did not have that, and the user did not say what he is using to mirror. But you only need that after a backout after running at the new site. On Tue, Feb 14, 2012 at 3:54 PM, Pommier, Rex R. <rex.pomm...@cnasurety.com> wrote: > Mike, > > Wouldn't number 10 be a massive amount of unnecessary work and replication? I was under the impression that if you had replication going between the two arrays and you suspended the replication, that you could bring up the replication targets in a read/write mode on the new servers. If you had to back out, after shutting the new servers down, you could "unsuspend" the replication and data that had changed on the source volumes would be replicated to the targets, and data on the targets that had changed would also have the source data pushed to overlay the changed targets. Is this not how replication works? > > Rex > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mike Schwab > Sent: Tuesday, February 14, 2012 2:59 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Changing sysplex hardware > > 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. -- Mike A Schwab, Springfield IL USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
