I vote for the RACF profile. This is what that mechanism was designed for. The dataset does not just disappear. In ISPF, you get a very explicit prompt that what you're doing is potentially dangerous and requires extra care. Furthermore, you don't need any special cleanup process afterwards as you would with tweaking GRS.
In my shop, creation of a special, even temporary RACF profile requires approval. As a senior sysprog, I'm blessed with access to profile STGADMIN.DPDSRN.* . This allows me to handle any dataset without hoopla. I do this responsibly and very infrequently. 'False contention' within GRS can cause production failures, not just inconvenience. I believe that a shop needs a process in place to fix these problems before they become Sev 1 incidents. . . . 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 jo.skip.robin...@gmail.com > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Tom Marchant > Sent: Wednesday, January 27, 2016 08:33 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued. > > On Wed, 27 Jan 2016 09:37:29 -0600, Ed Gould wrote: > > >Try disabling the VVDS on the volume > >amaspzap the dataset to change the name. > >delete the dataset with iehprogm > >enable the vvds on the volume > > ITYM disable the VTOC index. I wouldn't want to do it that way. > I think that what Kees suggested is a better solution. Tell GRS not to > propagate > the ENQ. > > -- > Tom Marchant ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
