Actually not. It is possible (not recommended!) to have shared DASD with
different addresses.
Example: CPCa and CPCb are connected to same DASD box. CPCa use dev num
3000-33FF and CPCb use dev num 1000-13FF for the same devices.
Devices can be varied online on both CPCs - local and remote.
Note: CU does not know device number. It talks about UA and CUADD.
And again: it is better to use same numbering schema, even in case of
two IODFs. The above example is possible, but not recommended. From
machine point of view there is no difference, but from human point of
view same numbering is better.
--
Radoslaw Skorupka
Lodz, Poland
W dniu 14.07.2020 o 18:26, Jesse 1 Robinson pisze:
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
robin...@sce.com
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
Michael Babcock
Sent: Monday, July 13, 2020 11:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
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 <jesse1.robin...@sce.com>
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
robin...@sce.com
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On
Behalf Of Michael Babcock
Sent: Monday, July 13, 2020 7:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
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
<rwjack...@firsthorizon.com>
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
======================================================================
Jeśli nie jesteś adresatem tej wiadomości:
- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza)
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać
karze.
mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st.
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 0000025237,
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
01.01.2020 r. wynosi 169.401.468 złotych.
If you are not the addressee of this message:
- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have
printed out or saved).
This message may contain legally protected information, which may be used
exclusively by the addressee.Please be reminded that anyone who disseminates
(copies, distributes) this message or takes any similar action, violates the
law and may be penalised.
mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital
City of Warsaw, 12th Commercial Division of the National Court Register, KRS
0000025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN
169.401.468 as at 1 January 2020.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
