Hi Dennis,
We have run a z/OS 2 lpar monoplex config for a long time . We never share linklisted datasets or PDSEs between the lpars. We never directly update a linklisted dataset from the other lpar. Most of the linklisted datasets do have the same names in both lpars, catalogued only to the monoplex they belong to, on different DASD and those packs are online only to the lpar they belong to . When I migrate a member or a library from test to production, I copy the members/ library to a shared pack and then, from the shared pack copy to the linklist library. I don't do the copies through TSO, I use batch. I use batch for the audit trail and because it is my preference. If you are seeing indications of updates in PDSe cache that don't belong to the monplex, I would view that as a very risky condition. Linda ----- Original Message ----- From: "Dennis Longnecker" <dennis.longnec...@courts.wa.gov> To: IBM-MAIN@bama.ua.edu Sent: Tuesday, May 19, 2009 3:52:34 PM GMT -08:00 US/Canada Pacific Subject: Re: PDSE Anomaly? 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 numerous 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:ibm-m...@bama.ua.edu] On Behalf Of Linda Mooney Sent: Monday, May 18, 2009 3:36 PM To: IBM-MAIN@bama.ua.edu 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" <linda.lst...@comcast.net> To: IBM-MAIN@bama.ua.edu 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" <dennis.longnec...@courts.wa.gov> To: IBM-MAIN@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
