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.
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 jo.skip.robin...@att.net > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Jim Mulder > Sent: Friday, January 29, 2016 01:25 PM > To: IBM-MAIN@LISTSERV.UA.EDU > 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:lists...@listserv.ua.edu> lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
