I would think from a dataset perspective you would be okay as the catalog would track extents/allocation, well assuming the new volume was online to the other lpar trying to read it and the catalogs are all shared. If they are extended format datasets that may/maybe be an issue. Also assumming you don't migrate with HSM like you stated, it should work as clear as mud. Im hoping you don't have different catalogs sharing the same volume as that would be ugly/interesting.
Thanks Ms. Terri E. Shaffer [email protected] Engineer J.P.Morgan Chase & Co. GTI DCT ECS Core Services zSoftware Group / Emerging Technologies Office: # 614-213-3467 Cell: # 412-519-2592 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Brian Fraser Sent: Wednesday, September 23, 2009 11:22 AM To: [email protected] Subject: Sharing Data between SMSPLEXES. 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. We also need to make sure that HSM cant migrate datasets from these volumes because the other HSM wont be able to recall them. 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? Brian ---------------------------------------------------------------------- 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 This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. ---------------------------------------------------------------------- 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
