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:[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
