Read/write sharing of PDSEs between z/OS images not in the same sysplex is incredibly dangerous, and very much not supported. What happens when you do share read/write between PDSEs is undefined; if you're lucky, you can recover, if you aren't, you have to restore the dataset from backup. Read-only sharing between images works, but is also not supported.
I don't think IBM has done enough to get this message out, because questions like this seem to pop up on a regular basis, but, very simply, do not make updates of any sort to a PDSE that is being shared beyond the boundaries of a sysplex. SMS and other things cache data about the structure and contents of PDSEs, and they trust that the cached data matches reality, and if you make an update from outside the sysplex, the cached data does not match the contents of the PDSE, and at the least weird, and at the worst bad, things are pretty much guaranteed to happen. If possible, I'd suggest restoring your DB2PROD.SDSNLOAD from backup, and if you're going to make changes to it, only do so when all the images accessing it outside the bounds of the sysplex of the image making the update are down. If that's not possible, you need to create multiple instances of DB2PROD.SDSNLOAD, one for each sysplex accessing it. --- Kevin McKenzie External Phone: 845-435-8282, Tie-line: 8-295-8282 z/OS BCP SVT, Dept FXKA, Bldg 706/2D38 From: "Longnecker, Dennis" <[email protected]> To: [email protected] Date: 05/19/2009 07:01 PM Subject: Re: PDSE Anomaly? Sent by: IBM Mainframe Discussion List <[email protected]> Exactly right.... two monoplex LPARS. In my situation on LPAR 1 DB2PROD.SDSNLOAD is cataloged on SYS033 LPAR 2 DB2PROD.SDSNLOAD is cataloged on SYS033 On LPAR 1, I copied a load module from DSN910.SDSNLOAD to the DB2PROD.SDSNLOAD library. On LPAR 2, I could not see the updated load module in DB2PROD.SDSNLOAD (on sys033); even after LLA and after numeros IPL's. ONLY after specifying the volser (SYS033) in the tso browse was it able to see the correct module. THEN, without specifying the volume serial number it displayed okay. Confusing -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Linda Mooney Sent: Monday, May 18, 2009 3:36 PM To: [email protected] Subject: Re: PDSE Anomaly? Hi Dennis, Mark is right in his comments. This could be bad if you are in a sysplex. In my response I was assuming two monoplex lpars. Linda ----- Original Message ----- From: "Linda Mooney" <[email protected]> To: [email protected] Sent: Monday, May 18, 2009 3:32:12 PM GMT -08:00 US/Canada Pacific Subject: Re: PDSE Anomaly? Hi Dennis, We have to watch out for this too. If you have a same name dataset on two different lpars and the alias is related to one user catalog one one lpar and to a different user catalog on the other lpar, you will see this behavior as each lpar will supply the correct dataset for its catalog lookup. When you supply the volser, the catalog lookup is bypassed - only the named volume is searched for the dataset. You can confirm this is your issue by doing a IDCAMS listcat on each lpar. Linda ----- Original Message ----- From: "Dennis Longnecker" <[email protected]> To: [email protected] Sent: Monday, May 18, 2009 1:53:48 PM GMT -08:00 US/Canada Pacific Subject: PDSE Anomaly? On my test lpar I applied some DB2 maintenance to a module. I could browse the module and indeed the fix was on. On my production LPAR, I wanted to copy that module over to the product libraries, so I did a TSO =3.3 copy and placed it in the production load library. I browsed that production load library, and the fix was not on. I browsed the original library, and the fix was not on. The original library is cataloged to the same volume (usercat), so I know it was pointing to the same place. I tried LLA, refreshes, inactivating LLA, and even IPL'ing, but could not see the fix on the load libraries from my production LPAR (still looked good in test). Finally, on the TSO =1 screen, I entered the dataset name AND the volser and then I could see that the fix was on. I went out and went back in without specifying the volser, and the fix was STILL on. It appears it was cached or something, even through an IPL....? Any suggestions? Dennis ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
