The 'bypass phantom enqueue' mechanism is really just that: ignore ENQ for a like named data set that *I* know resides on a different volume from the one in use. In OP's case, the ENQ is for the very data set that he needs to rename. I doubt that this would even work: I believe that an open data set has additional layers of protection. In any case I strongly advise *against* trying to circumvent a real ENQ on a real resource. If you're old enough, you learned as a kid that it's not nice to fool Mother Nature. That's not an idle threat.
I still advise to FORCE any userid(s) that won't go away gently. -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Paul Gilmartin Sent: Monday, October 7, 2019 9:49 AM To: [email protected] Subject: (External):Re: how to force a free of ispf allocated Dataset On Mon, 7 Oct 2019 08:55:55 -0500, Jeffrey Holst wrote: >I seem to recall that there is a program on CBTTAPE that can call IDCAMS or >IEHPROGM but intercepts the and ignores the ENQ on the dataset to be renamed >(or deleted). There is a certain danger to it, so it performs a security check >to try to restrict it use to only those who are authorized. I have used this >in the past to re-allocate perpetually allocated libraries on a cloned sysres >volume. And I have used it in circumstances such as the OP brought up. Just >use with extreme caution. > I believe IBM now supplies such a utility. It requires operator confirmation. "perpetually allocated" in this case only because of a shortcoming of GRS design. It's ignorant that the ENQed DSN is actually on a different volume. Formerly, the alternative was to zap the VTOC. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
