A final caution. You will need to do DASD housekeeping on the DR system. In order to do that remotely, you will need to put DR volumes online to prod. That will require unique device addresses. Just saying.
. . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW [email protected] -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Michael Babcock Sent: Monday, July 13, 2020 11:33 AM To: [email protected] Subject: (External):Re: Two Processors and One IODF CAUTION EXTERNAL EMAIL Ours is simply a DR site so currently we don’t have that requirement. On Mon, Jul 13, 2020 at 11:27 AM Jesse 1 Robinson <[email protected]> wrote: > We mirror with XRC, which I believe is Global Mirror. (I cannot keep > the current lingo straight.) In my shop, we have a business need to > put any device--DASD or tape--online to any LPAR regardless of > location. In order to do that, device addresses *must* be unique. If > you have absolutely no need to do that, then I don't think uniqueness > is required. OTOH is costs little to make them unique. If you don't do > it from the get-go, it will be very difficult in the future. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > [email protected] > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of Michael Babcock > Sent: Monday, July 13, 2020 7:10 AM > To: [email protected] > Subject: (External):Re: Two Processors and One IODF > > CAUTION EXTERNAL EMAIL > > Thanks! > > We are using Global Mirror for replication. Not sure if using the > same device addresses will be a problem or not for GM. > > So, does everyone recommend different device addresses? > > On Sat, Jul 11, 2020 at 1:01 PM Jackson, Rob > <[email protected]> > wrote: > > > I don't know if anyone has pointed it out, but if this is a brand > > new, vanilla CEC, before you even have to worry about an IODF, you > > need an IOCDS. Generally you create that deck from an IODF, and I > > can't imagine you would choose not to. All of our CECs are defined > > in one IODF. For a new machine across the state, we sent the IOCDS > > deck for the target CEC (and common ICC configs) to the CE, and he > > put them on a thumb drive; we then ran stand-alone IOCP to load the > > HSA. Then with any (I would hope) form of replication you use, the > > IODF needed for all the recovery LPARs is "just already there" on > > your recovery > SYS1.IPLPARM/IODF volume. > > > > Our DASD CUs and device addresses are different (I'm thinking they > > had to be for either flavor of replication), but we don't have that > > many, so we don't have to worry about running out. Our LPAR numbers > > are the same on all CECs, and our OS configs are defined only once > > and are used on all respective LPARs. > > > > There's nothing to it, and I don't know of a single reason not to > > have one common IODF. > > > > First Horizon Bank > > Mainframe Technical Support -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
