I agree for the most part, but if you know that SYS1.PARMLIB is always going to be a different local data set on each system (I assume there is a different master catalog also), then I don't see any harm in a specific exclusion. I ran that way in many shops (usually MIM/MII as opposed to GRS) back "in the day" before shared master catalogs and sysplexes were all the rage. Other local data sets needed to be excluded also (you couldn't always chose your own names for all the operational data sets - SYS1.LOGREC for example).
So to answer the OP, it would be done like this: RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSDSN) RNAME(SYS1.PARMLIB) RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SPFEDIT) RNAME(SYS1.PARMLIB) On the other hand, if SYS1.PARMLIB is the only concern, and it isn't an operational issue (batch job enq delay due to false contention), it's certainly easy enough to control yourself and live with the minor inconvenience of not being able to edit the same named SYS1.PARMLIB member on each system at the same time. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:[email protected] Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ On Wed, 27 Apr 2011 14:56:34 -0700, Skip Robinson <[email protected]> wrote: >One of the (in my opinion) few historic deficiencies of MVS is the >inability to distinguish like-named data sets on different volumes. GRS >(any mode) communicates the DSN around the complex but not the volser. You >will inevitably get a conflict trying to edit two at the same time even >though you know that are different. GRS does not. > >Best not to remove protection for ease of editing. Disaster is the >ultimate inconvenience. > >. >. >JO.Skip Robinson >SCE Infrastructure Technology Services >Electric Dragon Team Paddler >SHARE MVS Program Co-Manager >626-302-7535 Office >323-715-0595 Mobile >[email protected] > > > >From: sunil mirchandani <[email protected]> >To: [email protected] >Date: 04/27/2011 02:09 PM >Subject: Regarding GRSRNLxx member >Sent by: IBM Mainframe Discussion List <[email protected]> > > > >Hello All, > >I am not able to edit member of sys1.parmlib datasets at the same time >from >two lpars which are in sysplex, even though the datasets are on different >volumes. > >More clearly:- when i tried to edit CLOCK00 member from LPAR A and at >the >same time when i tried to edit CLOCK00 member from LPARB, it says member >in >use though volumes are different. > >LPAR A:- SYS1.PARMLIB VOl=XXXXXX >LPAR B:- SYS1.PARMLIB VOl=YYYYYY > >GRS MODE=STAR > >As per my understanding the i have to make change in GRSRNLxx member in >both the lpars and also keep it identical. but i am confused where should >i >make the entry for SYS1.PARMLIB in SYSTEMS exclusion or SYSTEM inclusion >and >why ? >(To ensure that resources are treated as you want them to be without >changes >to your applications, global resource serialization provides three >resource >name lists (RNLs): > >The *SYSTEM inclusion RNL lists resources requested with a scope of >SYSTEM*that you want global resource serialization to treat as global >resources. > >The *SYSTEMS exclusion RNL lists resources requested with a scope of >SYSTEMS >* that you want global resource serialization to treat as local resources. > >The *RESERVE conversion RNL *lists resources requested on the RESERVE >macro >that you want global resource serialization to suppress the reserve. > >Could any one help on this and throw some more light and make it clear. > >Thanks Much in Advance. >-- >Thanks & Regards: >Sunil M "Yesterday I dared to struggle. Today I dare to win" > > >---------------------------------------------------------------------- >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
