On 29 Jan 2016 20:48:15 -0800, in bit.listserv.ibm-main Skip wrote: >I finally got TSO access. Yay for me. Meaning that I can experiment. I'm >grateful to this thread for education on what to expect in a crunch. Here's >what I found as a user who has access to the magic RACF profile. > Could data sets be set up in different catalogs in the bronze-plex with GRS told not to propagate the enqueue (i.e. local to each system) in the 2 LPARS? If that can be done, would the experiment work differently? Would any special access be needed?
Clark Morris > >1. Allocated two SMS managed data sets from two members of the bronze-plex. >Same name, different volumes. Cataloged in two different user catalogs. That >is, two entirely different datasets associated by name only. Allocated SHR >on one system. Tried to rename on the other system. Got 'data set in use' >with no opportunity to override GRS. Total failure. > > > >2. Allocated two data sets as in #1 except HLQ SYS1, no SMS involved. >Cataloged on both systems in two different master catalogs. Got the same >failure: no can do. No opportunity to override GRS. I began to doubt the >efficacy of the magic profile. > > > >3. Uncatalogued the data set in #2 on the second system. Still on the same >volume, still enqueued. Note that this cannot be done with SMS data set. >This time I got a whole nother sequence. > > > >+--------------------------------------------------------------------------- >--+ > >| Rename Data Set In Use >| > >| Command ===> >| > >| >| > >| Data Set Name . : SYS1.TEST.DELETE | > >| Volume . . . . : xxxxxx >| > >| >| > >| The system detected that a data set with the above name is in use >| > >| (possibly on another system) but it cannot determine whether it is the >| > >| data set you wish to rename. If it is the same data set and any program >| > >| has it open, renaming it could cause serious system and data integrity >| > >| problems. >| > >| >| > >| You have the extra security authority to rename the data set even though >| > >| its name is in use. Refer to the DFSMS documentation on the RENAME macro >| > >| for further information. >| > >| >| > >| Instructions: >| > >| Press ENTER to override data set name protection and rename the data >| > >| set. >| > >| Enter CANCEL or EXIT to cancel the rename request. >| > >| >| > >| >| > >+--------------------------------------------------------------------------- >--+ > > > >I have to conclude from this experiment that cataloging makes all the >difference. SMS is a factor only because it requires that all datasets be >cataloged. If a dataset can be uncataloged, then the RACF profile allows >that dataset to be renamed despite the GRS enqueue. > >. > >. > >. > >J.O.Skip Robinson > >Southern California Edison Company > >Electric Dragon Team Paddler > >SHARE MVS Program Co-Manager > >323-715-0595 Mobile > >[email protected] > > > >> -----Original Message----- > >> From: IBM Mainframe Discussion List [mailto:[email protected]] > >> On Behalf Of Jim Mulder > >> Sent: Friday, January 29, 2016 01:25 PM > >> To: [email protected] > >> Subject: Re: Deleting a dataset that GRS has enqueued. > >> > >> > We took the easy way out and brought down the two STCs that had the > >> > SMS dataset enqueued, then deleted the version of the dataset that was > >> > not being used. > >> > > >> > It was mentioned in this thread that GRS could have been modified to > >> > change the scope of the enqueue on the LPAR that the dataset was not > >> > being used on by making it local. Therefore no longer considered in > >> > use by GRS. I did not try this, but wonder if this was done for a > >> > dataset that was already enqueued if this would work... thoughts? > >> > > >> > I never found or saw mention a straight forward IBM supported way to > >> > delete or rename a SMS dataset in this situation. If someone comes > >> > across a way please post I am curious. > >> > >> I asked Wayne Rhoten about this. He replied: > >> > >> "I worked on that project and wrote some of the code. I think that the >reason > >> that it does not apply to an SMS-managed data set is that it conflicts >with the > >> concept that you cannot have two SMS-managed data sets with the same > >> name. The project was designed for the system programmer that is building > >> another system. For example he might have multiple SYS1.MACLIBs." > >> > >> So dealing with the situation of having separate catalogs and SMS-plexes > >> within the same sysplex (and thus allowing more than one SMS-managed data > >> set with the same name in the same sysplex) was not a design consideration > >> for that project. > >> > >> Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY > >> > >> > >> ---------------------------------------------------------------------- > >> For IBM-MAIN subscribe / signoff / archive access instructions, send email >to > >> <mailto:[email protected]> [email protected] with the >message: INFO IBM-MAIN > > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
