What you're missing is that the world can be more complicated than the playbook indicates. We for example created a 'bronze-plex' some years ago. (Please lower your flame throwers.) We bolted together two different sysplexes in order to satisfy an IBM requirement for sysplex pricing. These sysplexes had different histories representing different workloads and different users. Simply mushing everything together into one mud pie was out of the question. So the systems share as little as required for sysplex to function.
This means that the systems have multiple datasets of the same name residing on different volumes. GRS however is a sysplex function, so there's only one. GRS does not know from volume, only dataset name. Hence an enqueue on one system creates a 'false contention' on the other system for that DSN. We have managed through process tweaks and user education to live with this discomfort. But if we needed to whack one of the datasets for whatever reason, we would hit this very problem. Does SMS complicate cleanup? . . . 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 Doug Henry > Sent: Thursday, January 28, 2016 08:47 AM > To: [email protected] > Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued. > > I will admit that I haven't followed this entire thread but this facility is > designed to rename datasets that exist on multiple volumes (like ipl volumes). > For SMS managed datasets they must be cataloged and therefore can't exist > on multiple volumes. > Therefore the enq is held because that dataset is the one it is held for. > Am I missing something ? > > Doug > > On Thu, 28 Jan 2016 08:37:36 -0800, Skip Robinson > <[email protected]> wrote: > > >I for one would appreciate a comment from someone in DFSMS on this > >topic. It's really important to know *in advance* whether the RACF > >approach will work for an SMS managed dataset. Or an experiment by > >someone who can actually try it. (Unfortunately I cannot at the > >moment.) > >> -----Original Message----- > >> From: IBM Mainframe Discussion List [mailto:IBM- > [email protected]] > >> On Behalf Of Walt Farrell <[email protected]> wrote: > >> > >> >I thought from discussions here a few years ago that IBM has > >> >provided a facility that supports renaming of an ENQUEUEd DSN, in > >> >the VTOC, after requesting confirmation from the operators' console > >> >that that DSN on that volume is *not* the one to which the ENQ pertains. > >> > > >> >Don't know how it interacts with catalog, SMS, indexed VTOCs, > >> >automated operations, ... This amounts to institutionalizing the > >> >technique of zapping the VTOC while placing the integrity burden on a > human being. > >> > >> Yes, via the RACF profiles previously mentioned. But someone else > >> pointed out the line in the documentation stating "Does not work for > >> SMS-managed data sets." > >> > >> I have no idea why that restriction exists. I don't recall hearing > >> about it when we in RACF designed our part of that support. > >> > >> -- > >> Walt ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
