ISPF 3.4 lets you work with a dataset if is on a volume where it is NOT allocated, and you allow the override to let you process with the action you want to take. Of course, you need the right RACF security. I think this is what is needed in DF/DSS as well. If you want to dump a dataset with an ENQ, but the dataset is not on the volume where the ENQ originates from, then dump the file. This should not cause any problems.
Art Zeigler ________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Mark Zelden <[email protected]> Sent: Monday, October 16, 2023 1:11 PM To: [email protected] <[email protected]> Subject: Re: DFDSS RFE - Please read / vote On Sun, 15 Oct 2023 12:24:35 +0000, Peter Relson <[email protected]> wrote: ><snip> >If prodhlq.product.LINKLIB is ENQed (in this case you can presume it is due to >being in the LNKLST on the driving system), you get this error: > >ADR497E (001)-CATLG(07), A CATALOG ERROR OCCURRED WHILE DELETING UNCATALOGED >DATA SET prodhlq.product.LINKLIB. RETURN CODE IS 102, REASON >CODE IS FP-007 ></snip> > > >I will leave the substantive issues to those who know DFDSS, but I trust that >it is understood that if this is related to the ENQ obtained by allocation >(the SYSDSN ENQ, obtained shared for DISP=SHR, exclusive for DISP=OLD (in this >case DFDSS might want DISP=OLD), this is the way z/OS works. Whether you like >it or not, the SYSDSN ENQ RNAME does not include the volume ID; in general, >that could not be changed compatibly. > >And that is why, for example, dynamic LNKLST provides its LNKLST >UNALLOCATE/ALLOCATE functions (intended to be used only for this sort of >situation) to un-do (and later re-do) the allocations it has put in place to >protect you from deleting the data sets in the LNKLST. Once those allocations >are undone, you can deal with an uncataloged data set of the same name as a >data set in the LNKLST. >Peter Relson >z/OS Core Technology Design > Yes, that could be done. I also mentioned that work around to some people at the shop. But taking the entire LNKLST ENQ away from 9 systems in the sysplex just to copy the product to the "ISV sysres", even for a few minutes, is worse than letting it fail and renaming the lib / deleting it with ISPF (at least in my view). Of course we can plan and re-name / delete ahead of time or use other tools I have to do that all in batch before the copy. I've just never needed to do this with FDR for over 30 years of having ISV datasets (or IBM program products) as an extension of the sysres set. Hence the RFE. I don't know what FDR does behind the scenes to accomplish this, but it does without any issue. Best Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:[email protected] Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
