On 01/28/2016 10:37 AM, Skip Robinson 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.) > > . > . > . > 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 Walt Farrell >> Sent: Thursday, January 28, 2016 06:52 AM >> To: [email protected] >> Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued. >> >> On Wed, 27 Jan 2016 18:40:45 -0600, Paul Gilmartin >> <[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 > There seems to have been all sorts of impediments put in place to prevent one from touching SMS data sets from a system on which they are not properly cataloged. My recollection is that it was not possible to allocate and actually open even an un-enqueued SMS library on a specified volume from a running system whose catalogs indicated a different volume without getting a failure. Renaming an apparently-enqueued data set would be a more unnatural act than this, yet there obviously should be a better way to do this than with kludges.
There ought to be some restricted way (assuming it's not there already and just unadvertised), with IDCAMS commands and without the kludges everyone has been describing here and with proper RACF authorization, for a System Programmer to rename, delete, or create an SMS data set on a specific Volume and in a specific Catalog that belong to another *inactive* system, even though the name may be enqueued on the running system and the name of the data set is such that there is no way to make it properly catalog-accessible on the running system; and since the SMS definitions on the two systems could be incompatible, it would have to be possible for assignment of SMS attributes on a created target data set to be explicitly assigned and bypass any SMS definitions on the running system. It seemed to take decades for IBM to come up with decent support to allow SysProgs to rename apparently-but-not-really-enqueued data sets, but from this thread that fix appears incomplete when SMS data sets are involved, and an extended solution is obviously required. -- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
