Given the constraints you have imposed, I would suggest a 3rd
('platimum') SMSplex for this data.
i.e. shared ucat,. Volumes, SMS cds's, HSMplex,...
Comments interspersed:
>We have 2 SMSPLEXES within a bronze SYSPLEX.
>GRS is common to all LPARS, but most everything else is not.
>Now we have a new DB2 application coming that will require application
>datasets which will be required to be written to from all LPARS in the
PLEX.
>I've shared volumes before by having a storage group which is written
to
>from one SMSPLEX being online and in read mode from another plex with
no
>problems, but for both sides to be able to allocate, write & extend
datasets
>then I'm wondering if there's any gottchas coming at me.
>We can create the same Storage Group on both SMSes and define all the
same
>volumes within. Of course we need to have procedures in place to ensure
that
>someone doesn't go adding or removing volumes to one side and not the
other.
This is handled by SMS. Since there are shared SMS CDS's, any change
from one image to the other will be automatically communicated via the
CDS's. See my comment above regarding a "platinum" SMSplex.
>We also need to make sure that HSM cant migrate datasets from these
volumes
>because the other HSM wont be able to recall them.
There are three possibilities here. One is to route all HSM functions to
a particular image via the SG attribute "MIGRATE SYSTEM or SYSTEM
GROUP". I have never used this so check the manuals for details. Another
possibility is to set up an SMSplex/HSMplex for *ONLY THIS* data. I
*STRONGLY* suggest that if this is done, the boundaries of the
SMSplex/HSMplex and the data are congruent. i.e. set up a
SMSplex/HSMplex to only manage this set of volumes. All other
SMSplex/HSMplex's should ignore this pool. The third possibility is to
create an appropriate set of MC/SC/SG attribute that prevent migration.
Of course this means you will have to do storage management for this
pool the "old fashioned" way, by hand.
>My only real concern, is will it all hang together if/when one of these
dsns
>goes into extents on another candidate volume.
Will this cause any problems to any LPAR thats not in the SMS that
performed
>the extend?
Comes with XCF/GRS/SMS. This should cause no issues within the SMSplex.
HTH,
----------------------------------------------------------------------
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
