Re: DFDSS RFE - Please read / vote
You didn't write that thy have unique names. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי From: IBM Mainframe Discussion List on behalf of Mark Zelden Sent: Monday, October 16, 2023 1:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFDSS RFE - Please read / vote On Sun, 15 Oct 2023 13:47:39 +, Seymour J Metz wrote: >You might consider an alternate deployment strategy > >* A target and dlib zone for each IPL volume. >* Secondary res volsers based on IPL volser >* Symbols based on IPL volser >* File system names based on IPL volser >* Data set names on other than target or dlib based on IPL volser >* Indirect cataloging. >* LOADxx and IEASYMxx for above > >Having unique names for the data sets off the res volumes should resolve your >ENQ issue. > Re-read what I wrote. These are sysres datasets, indirectly catalogged. No different than SYS1.LINKLIB except they are not part of the OS. Best Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://secure-web.cisco.com/19zitwfINAm6vRlxP67zogOmf2dWvKOmWpXPKyjxpJJEdXNQF2bbNrhsrFANQKV4YnHgdwMh7Q_0dhAV-W81EmJAzDHgK1GjSkpOefK7VB77dG8oFB2TUq9kvS6eRMbm-sDk_EYMcO8GxmxBaSbpkcfKoqkU8qT9eYHVgsEf50_VV5Uvg8Z8A9eO_lUhNkUuDmT0cQ0ZGW4iRPafCV4ZuYnqfp13PD8RmOq72brRSuaX-mGCbvTb-waRltiBmkJj6fxIr-De021iVECgZfH2602Ut13mh8mPxqLmpkK37s32l9-iv53ka0ysaZkVhVhE1HnqYEyOjbqx4CFEmaISlUjObiBpo5mLwHVDM6ZmT4UJ5vfeu-6gHgnky2TDMiSoyBz9K1D5u9X3wD8iBOen3qRPlAP0vJnhPLOv0Bd3WIlA/http%3A%2F%2Fwww.mzelden.com%2Fmvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS RFE - Please read / vote
On Mon, 16 Oct 2023 17:38:09 +, Art Zeigler wrote: >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. > I already mentioned this in the first post and that's what's being done now. This is a large environment... many sysplexes and lots of very junior people supporting it. I'm concerned about someone making a mistake and forgetting to put the volser on ISPF 3.4 and deleting a live dataset in the LNKST, in use by TSO/ISPF or an STC. BTW, I don't think people can see all the text in the RFE (even though I put in my first post). You can also read my comments though. https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3862 Best Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS RFE - Please read / vote
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 on behalf of Mark Zelden Sent: Monday, October 16, 2023 1:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFDSS RFE - Please read / vote On Sun, 15 Oct 2023 12:24:35 +, Peter Relson wrote: > >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 > > > >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:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS RFE - Please read / vote
I did read that Mark, but didn’t provide enough detail., or skimmed over it. So, for my ISV extension volume a few things occur at the beginning of maintenance rollout time: 1. All ISV products get maintained via vendor provided processes with datasets that contain a ver/release qualifier 2. Clone old master volume to new master volume as new baseline 3. When cloning updated ISV libraries to master, the datasets get scratched via IEHPROGM on the new master volume, and then updated libraries are copied with RENAMEU to remove the ver/release info. 4. FDREPORT job is run to generate/re-generate indirect catalog entries (to pickup any possibly new datasets that were added), and IDCAMS step to create. TOL(ENQF) is honored for both source and target datasets with a few exceptions (mostly for the things you mentioned already, reallocating, etc). COPY DS(INC(SYSV.IDP.FDREPORT.V5490SP2.CLIST)) - RENUNC((SYSV.IDP.FDREPORT.V5490SP2.CLIST, - SYSV.IDP.FDREPORT.CLIST)) - LIDY(VND005) ODY(VSM02A) BYPASSACS(**) NSC REPLACEU - ALLDATA(*) TOL(ENQF) SPHERE ALLX SHARE Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of Mark Zelden Date: Monday, October 16, 2023 at 12:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFDSS RFE - Please read / vote On Sun, 15 Oct 2023 00: 31: 20 +, Jousma, David wrote: >Mark, > >I have the same cloning process as you logically. I know exactly the problem you face. Your rfe makes sense. > >I get around it by On Sun, 15 Oct 2023 00:31:20 +, Jousma, David wrote: >Mark, > >I have the same cloning process as you logically. I know exactly the problem >you face. Your rfe makes sense. > >I get around it by cloning at the volume level, but there is always the >outlier that needs to be cloned by itself, or the once in awhile fix that >needs to be made.When I run into that I either rename then delete the >enqueued dataset via ispf, and then reload, or if the dataset is actually in >use validly, I use idcams to delete all members, compress, then reload via >iebcopy. > Re-read what I wrote though. I have no problem cloning the sysres set since that is also done on the volume level. The problem is ISV or IBM program products that get "added" to the maintenance sysres in preparation for cloning. Around 40 different products that get copied to the volume at any given time after maintenance to one of those products. Then I clone the IBM sysres volumes and the program product volumes as one set using full volume copies (except for zFS files that are logically copied and have the sysres name as part of the dataset name). Best Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: https://urldefense.com/v3/__http://www.mzelden.com/mvsutil.html__;!!MwwqYLOC6b6whF7V!l5PVMhb0Ho14o2qfG-4mGoh8trURMMwWV_3J4TJPFXbbuOn6CL5M0mzwZaqcjU4LMJ1WEu-fzBOtjPk$<https://urldefense.com/v3/__http:/www.mzelden.com/mvsutil.html__;!!MwwqYLOC6b6whF7V!l5PVMhb0Ho14o2qfG-4mGoh8trURMMwWV_3J4TJPFXbbuOn6CL5M0mzwZaqcjU4LMJ1WEu-fzBOtjPk$> -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS RFE - Please read / vote
On Sun, 15 Oct 2023 12:24:35 +, Peter Relson wrote: > >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 > > > >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:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS RFE - Please read / vote
On Sun, 15 Oct 2023 13:47:39 +, Seymour J Metz wrote: >You might consider an alternate deployment strategy > >* A target and dlib zone for each IPL volume. >* Secondary res volsers based on IPL volser >* Symbols based on IPL volser >* File system names based on IPL volser >* Data set names on other than target or dlib based on IPL volser >* Indirect cataloging. >* LOADxx and IEASYMxx for above > >Having unique names for the data sets off the res volumes should resolve your >ENQ issue. > Re-read what I wrote. These are sysres datasets, indirectly catalogged. No different than SYS1.LINKLIB except they are not part of the OS. Best Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS RFE - Please read / vote
On Sun, 15 Oct 2023 00:31:20 +, Jousma, David wrote: >Mark, > >I have the same cloning process as you logically. I know exactly the problem >you face. Your rfe makes sense. > >I get around it by cloning at the volume level, but there is always the >outlier that needs to be cloned by itself, or the once in awhile fix that >needs to be made.When I run into that I either rename then delete the >enqueued dataset via ispf, and then reload, or if the dataset is actually in >use validly, I use idcams to delete all members, compress, then reload via >iebcopy. > Re-read what I wrote though. I have no problem cloning the sysres set since that is also done on the volume level. The problem is ISV or IBM program products that get "added" to the maintenance sysres in preparation for cloning. Around 40 different products that get copied to the volume at any given time after maintenance to one of those products. Then I clone the IBM sysres volumes and the program product volumes as one set using full volume copies (except for zFS files that are logically copied and have the sysres name as part of the dataset name). Best Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS RFE - Please read / vote
You might consider an alternate deployment strategy * A target and dlib zone for each IPL volume. * Secondary res volsers based on IPL volser * Symbols based on IPL volser * File system names based on IPL volser * Data set names on other than target or dlib based on IPL volser * Indirect cataloging. * LOADxx and IEASYMxx for above Having unique names for the data sets off the res volumes should resolve your ENQ issue. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי From: IBM Mainframe Discussion List on behalf of Mark Zelden Sent: Friday, October 13, 2023 10:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFDSS RFE - Please read / vote On Fri, 13 Oct 2023 15:31:42 -0500, Mark Zelden wrote: I've had some offline responses also. Including the suggestion to use TOLERATE(ENQFAILURE) which only applies to the input dataset. Let me explain again and show all the DFDSS control cards. I have an "program products" sysres that is an extension of IBM OS sysres. There is a maintenance version of that sysres, just like you have a maintenance IBM sysres that you apply SMP/E maintenance to. The PP sysres gets cloned along with the IBM sysres via full volume disk to disk copies. That is not a problem. That program products sysres (really 2 3390-27 volumes) has perhaps 40 IBM / ISV products. All the datasets are indirectly catalogued via Program product SMP/E target libs are copied (and renamed during the copy) to the PP maintenance sysres at various time. When maintenance for any give product is applied (or an upgrade) and is ready to roll out the sysprog copies the SMP/E targets to this maintenance sysres. So think of it as a volume were changes are staged for production. Then after cloning, the changes are rolled out as a package, be it with IBM OS maintenance, one product, several products, or any combination like that. This is done via rolling IPLs in a sysplex environment so as not to cause any application outages (usually half the LPARs one month, the other half the next month). Almost every product's main loadlib is in the LNKLST - at least anything that has associated production JCL, TSO CLISTs / EXECs, ISPxLIBs etc. If something is only used by an STC, it may not be in the LNKLST. This is to shield anyone from having to make JCL changes etc. (pretty standard stuff, right?). So many of these datasets being "staged" prior to cloning are ENQed. If the input library in the copy is larger than the one on the maintenance sysres volume, that is when DFDSS fails. If it doesn't have to scratch / reallocate the dataset that already exists to make it larger to accommodate the input data set size, it works fine. Here is a sample of the copy process with DFDSS, only there would be many more libraries copied / renamed than just a single one for almost all products. (another shortcoming of DFDSS compared to FDRCOPY where only the HLQ can be renamed and FDRCOPY can rename the hlq plus add / remove nodes for multiple datasets - dozens if I needed, in a single control statement, but I digress...) //SYSINDD * COPY DS( - INCLUDE( - smphlq.product.V6R3.LINKLIB - ) - ) - RENAMEU( - (smphlq.product.V6R3.LINKLIB - prodhlq.product.LINKLIB)- ) - SHARE TOL(ENQF) PROCESS(SYS1) - BYPASSACS(**) - NULLSTORCLAS- LIDY(inpvol)- OUTDYNAM(outvol,SYSALLDA) - REPLACEUNCONDITIONAL - WAIT(2,2) ALLDATA(*) ALLEXCP /* 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 ERROR OCCURRED WHILE DELETING UNCATALOGED DATA SET ** VOTE here by clicking the vote icon at the top left! https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3862 Regards, Mark >Sorry for top posting... > >Let's address your comments one keyword at a time: > >DELETE - deletes the source (input) dataset. Ouch! Lets not delete my SMP/E >target libs during copy to my sysres set please! > >PURGE - overlays an output dataset that has an expiration date not yet >reached. Not applicable. > >UNCOND - no such parm or abbreviation. I assume you mean >replaceunconditional, and that is already being done and doesn't matter. > >The deficiency is DADSM. This is how DFSMSdss is handling this scenaro (it >attempts to scratch the DSN to reallocate a bigger dsn on copy if required). >DADSM can't scratch the DSN because the DSN is ENQ'd. > >ADR497E (001)-CATLG(07), A CATALOG ERROR OCCURRED WHILE DELETING UNCATALOGED >DATA SET SYNCSORT.SYNCLINK. RETURN CODE IS 102, REASON >CODE IS FP-
Re: DFDSS RFE - Please read / vote
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 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS RFE - Please read / vote
Mark, I have the same cloning process as you logically. I know exactly the problem you face. Your rfe makes sense. I get around it by cloning at the volume level, but there is always the outlier that needs to be cloned by itself, or the once in awhile fix that needs to be made.When I run into that I either rename then delete the enqueued dataset via ispf, and then reload, or if the dataset is actually in use validly, I use idcams to delete all members, compress, then reload via iebcopy. There is a restore with tol(enqf) I believe too. Dave Jousma Vice President | Director, Technology Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 From: IBM Mainframe Discussion List on behalf of Mark Zelden Sent: Friday, October 13, 2023 10:55:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFDSS RFE - Please read / vote On Fri, 13 Oct 2023 15: 31: 42 -0500, Mark Zelden wrote: I've had some offline responses also. Including the suggestion to use TOLERATE(ENQFAILURE) which only applies to the input dataset. Let me explain again and show On Fri, 13 Oct 2023 15:31:42 -0500, Mark Zelden wrote: I've had some offline responses also. Including the suggestion to use TOLERATE(ENQFAILURE) which only applies to the input dataset. Let me explain again and show all the DFDSS control cards. I have an "program products" sysres that is an extension of IBM OS sysres. There is a maintenance version of that sysres, just like you have a maintenance IBM sysres that you apply SMP/E maintenance to. The PP sysres gets cloned along with the IBM sysres via full volume disk to disk copies. That is not a problem. That program products sysres (really 2 3390-27 volumes) has perhaps 40 IBM / ISV products. All the datasets are indirectly catalogued via Program product SMP/E target libs are copied (and renamed during the copy) to the PP maintenance sysres at various time. When maintenance for any give product is applied (or an upgrade) and is ready to roll out the sysprog copies the SMP/E targets to this maintenance sysres. So think of it as a volume were changes are staged for production. Then after cloning, the changes are rolled out as a package, be it with IBM OS maintenance, one product, several products, or any combination like that. This is done via rolling IPLs in a sysplex environment so as not to cause any application outages (usually half the LPARs one month, the other half the next month). Almost every product's main loadlib is in the LNKLST - at least anything that has associated production JCL, TSO CLISTs / EXECs, ISPxLIBs etc. If something is only used by an STC, it may not be in the LNKLST. This is to shield anyone from having to make JCL changes etc. (pretty standard stuff, right?). So many of these datasets being "staged" prior to cloning are ENQed. If the input library in the copy is larger than the one on the maintenance sysres volume, that is when DFDSS fails. If it doesn't have to scratch / reallocate the dataset that already exists to make it larger to accommodate the input data set size, it works fine. Here is a sample of the copy process with DFDSS, only there would be many more libraries copied / renamed than just a single one for almost all products. (another shortcoming of DFDSS compared to FDRCOPY where only the HLQ can be renamed and FDRCOPY can rename the hlq plus add / remove nodes for multiple datasets - dozens if I needed, in a single control statement, but I digress...) //SYSINDD * COPY DS( - INCLUDE( - smphlq.product.V6R3.LINKLIB - ) - ) - RENAMEU( - (smphlq.product.V6R3.LINKLIB - prodhlq.product.LINKLIB)- ) - SHARE TOL(ENQF) PROCESS(SYS1) - BYPASSACS(**) - NULLSTORCLAS- LIDY(inpvol)- OUTDYNAM(outvol,SYSALLDA) - REPLACEUNCONDITIONAL - WAIT(2,2) ALLDATA(*) ALLEXCP /* 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 ERROR OCCURRED WHILE DELETING UNCATALOGED DATA SET ** VOTE here by clicking the vote icon at the top left! https://urldefense.com/v3/__https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3862__;!!MwwqYLOC6b6whF7V!l88xZXKbWy57EEOicntO2a0U2-ASRLcj7Ya5t5ggE89_A6unfsAePPoZPdaeGWNpUinbleEiMkvaePQ$ Regards, Mark >Sorry for top posting... > >Let's address your comments one keyword at a time: > >DELETE - deletes the source (input) dataset. Ouch! Lets not delete my SMP/E >target libs during copy to my sysres set please! > >PURGE - overlays an output dataset that has an expiration date not yet >reac
Re: DFDSS RFE - Please read / vote
On Fri, 13 Oct 2023 15:31:42 -0500, Mark Zelden wrote: I've had some offline responses also. Including the suggestion to use TOLERATE(ENQFAILURE) which only applies to the input dataset. Let me explain again and show all the DFDSS control cards. I have an "program products" sysres that is an extension of IBM OS sysres. There is a maintenance version of that sysres, just like you have a maintenance IBM sysres that you apply SMP/E maintenance to. The PP sysres gets cloned along with the IBM sysres via full volume disk to disk copies. That is not a problem. That program products sysres (really 2 3390-27 volumes) has perhaps 40 IBM / ISV products. All the datasets are indirectly catalogued via Program product SMP/E target libs are copied (and renamed during the copy) to the PP maintenance sysres at various time. When maintenance for any give product is applied (or an upgrade) and is ready to roll out the sysprog copies the SMP/E targets to this maintenance sysres. So think of it as a volume were changes are staged for production. Then after cloning, the changes are rolled out as a package, be it with IBM OS maintenance, one product, several products, or any combination like that. This is done via rolling IPLs in a sysplex environment so as not to cause any application outages (usually half the LPARs one month, the other half the next month). Almost every product's main loadlib is in the LNKLST - at least anything that has associated production JCL, TSO CLISTs / EXECs, ISPxLIBs etc. If something is only used by an STC, it may not be in the LNKLST. This is to shield anyone from having to make JCL changes etc. (pretty standard stuff, right?). So many of these datasets being "staged" prior to cloning are ENQed. If the input library in the copy is larger than the one on the maintenance sysres volume, that is when DFDSS fails. If it doesn't have to scratch / reallocate the dataset that already exists to make it larger to accommodate the input data set size, it works fine. Here is a sample of the copy process with DFDSS, only there would be many more libraries copied / renamed than just a single one for almost all products. (another shortcoming of DFDSS compared to FDRCOPY where only the HLQ can be renamed and FDRCOPY can rename the hlq plus add / remove nodes for multiple datasets - dozens if I needed, in a single control statement, but I digress...) //SYSINDD * COPY DS( - INCLUDE( - smphlq.product.V6R3.LINKLIB - ) - ) - RENAMEU( - (smphlq.product.V6R3.LINKLIB - prodhlq.product.LINKLIB)- ) - SHARE TOL(ENQF) PROCESS(SYS1) - BYPASSACS(**) - NULLSTORCLAS- LIDY(inpvol)- OUTDYNAM(outvol,SYSALLDA) - REPLACEUNCONDITIONAL - WAIT(2,2) ALLDATA(*) ALLEXCP /* 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 ERROR OCCURRED WHILE DELETING UNCATALOGED DATA SET ** VOTE here by clicking the vote icon at the top left! https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3862 Regards, Mark >Sorry for top posting... > >Let's address your comments one keyword at a time: > >DELETE - deletes the source (input) dataset. Ouch! Lets not delete my SMP/E >target libs during copy to my sysres set please! > >PURGE - overlays an output dataset that has an expiration date not yet >reached. Not applicable. > >UNCOND - no such parm or abbreviation. I assume you mean >replaceunconditional, and that is already being done and doesn't matter. > >The deficiency is DADSM. This is how DFSMSdss is handling this scenaro (it >attempts to scratch the DSN to reallocate a bigger dsn on copy if required). >DADSM can't scratch the DSN because the DSN is ENQ'd. > >ADR497E (001)-CATLG(07), A CATALOG ERROR OCCURRED WHILE DELETING UNCATALOGED >DATA SET SYNCSORT.SYNCLINK. RETURN CODE IS 102, REASON >CODE IS FP-007 > >You also will see: > >"ERROR OCCURRED WHILE DELETING UNCATALOGED DATA SET" > >Ironic since the CATALOG keyword is not used while copying over the indirectly >catalogged dataset on the maintenance sysres set. > >Not sure what FDRCOPY does under the covers... no access right now try try and >determine that. Perhaps it renames it first and deletes
Re: DFDSS RFE - Please read / vote
Sorry for top posting... Let's address your comments one keyword at a time: DELETE - deletes the source (input) dataset. Ouch! Lets not delete my SMP/E target libs during copy to my sysres set please! PURGE - overlays an output dataset that has an expiration date not yet reached. Not applicable. UNCOND - no such parm or abbreviation. I assume you mean replaceunconditional, and that is already being done and doesn't matter. The deficiency is DADSM. This is how DFSMSdss is handling this scenaro (it attempts to scratch the DSN to reallocate a bigger dsn on copy if required). DADSM can't scratch the DSN because the DSN is ENQ'd. ADR497E (001)-CATLG(07), A CATALOG ERROR OCCURRED WHILE DELETING UNCATALOGED DATA SET SYNCSORT.SYNCLINK. RETURN CODE IS 102, REASON CODE IS FP-007 You also will see: "ERROR OCCURRED WHILE DELETING UNCATALOGED DATA SET" Ironic since the CATALOG keyword is not used while copying over the indirectly catalogged dataset on the maintenance sysres set. Not sure what FDRCOPY does under the covers... no access right now try try and determine that. Perhaps it renames it first and deletes it with DADSM. But I know one does not need access to STGADMIN.DPDSRN.dsn_to_rename in order for it to work with FDRCOPY. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ On Thu, 12 Oct 2023 22:44:29 +, willie bunter wrote: > I thought the UNCOND DELETE PURGE parms could be used along with the COPY > command > >On Wednesday, October 11, 2023 at 05:00:17 p.m. EDT, Mark Zelden > wrote: > > Hi all, > >Please read / vote for this RFE. > > >"Provide abilty for DSS to be able to scratch and reallocate an in use data >set name that is not the actual dataset in use during a logical copy operation" > >https://ideas.ibm.com/ideas/ZOS-I-3862 > >I think you vote here: >https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3862 > >I was honestly shocked this is not supported in DFDSS. I've been using FDR >for over 30 years for this. > >I don't know if you can see the entire text, so I will copy it below to >explain the issue, but in summary: > >If you are copying a dataset to a maintenance sysres (target sysres that will >be cloned) and that DSN >is ENQd, the copy will work - unless the dataset needs to be scratched / >reallocated because the >input dataset is larger than the output one that already exists. I've been >supporting clients for >30 years that keep ISV (and IBM non-OS) products as an extension of the sysres >and recently >ran into this at a client that dumped FDR since they had DFDSS and ran into >this problem. > >If you know a way around the issue - shoot! IBM says it is not supported. >You can delete the >not in use dataset after rename (if allowed) but that is error prone since you >have to point to >the maintenance volume and I don't want JR. people doing this. One other work >around is >after the logical copy fails, you can run it again as physical since the >dataset is enlarged >on the first try, but just fails in scratch. BTW, "CATALOG" is never used in >this copy since >the datasets are indirectly catalogged. > >Now for the RFE main part of the RFE text: > >--- > >Putting maintenance onto a "target" / maintenance sysres volume or set has >been an MVS concept and cloning an IPLable sysres set (or swapping IPL sets) >"forever" . Many shops also put other IBM products or ISV products on a >secondary / tertiary sysres and indirectly catalog them so they are on the >sysres set. This is the only way to support rolling IPLs in a sysplex so >there are not application outages (another MVS concept). Since those >secondary / tertiary volumes are a combination of products, adding new >datasets is done via logical copy of a product's target libraries to the >target / maintenance sysres and those datasets are indirectly catalogged using >a system symbol like , , etc. The copy to the "target" system >(maintenance sysres) works fine even if the same named dataset is in use on >the live sysres set (be it in the LNKLST, TSO PROC, STC STEPLIB etc.). >EXCEPT... when the dataset needs to be enlarged as part of the copy process. >In that case you get message ADR497E RC 102 Reason code FP-007 and "ERROR >OCCURRED WHILE DELETING UNCATALOGED DATA SET" and the copy for that dataset >fails. However, the dataset to be "overlaid" (if you will), is not the >dataset in use so DFDSS should have the ability to enlarge it and do the copy. > The only solution is to use the DFSMS special SAF authority to rename a >dataset in use (STGADMIN.DPDSRN.dsn_to_rename) to rename the "target" dataset >on the maintenance volume, then
Re: DFDSS RFE - Please read / vote
I thought the UNCOND DELETE PURGE parms could be used along with the COPY command On Wednesday, October 11, 2023 at 05:00:17 p.m. EDT, Mark Zelden wrote: Hi all, Please read / vote for this RFE. "Provide abilty for DSS to be able to scratch and reallocate an in use data set name that is not the actual dataset in use during a logical copy operation" https://ideas.ibm.com/ideas/ZOS-I-3862 I think you vote here: https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3862 I was honestly shocked this is not supported in DFDSS. I've been using FDR for over 30 years for this. I don't know if you can see the entire text, so I will copy it below to explain the issue, but in summary: If you are copying a dataset to a maintenance sysres (target sysres that will be cloned) and that DSN is ENQd, the copy will work - unless the dataset needs to be scratched / reallocated because the input dataset is larger than the output one that already exists. I've been supporting clients for 30 years that keep ISV (and IBM non-OS) products as an extension of the sysres and recently ran into this at a client that dumped FDR since they had DFDSS and ran into this problem. If you know a way around the issue - shoot! IBM says it is not supported. You can delete the not in use dataset after rename (if allowed) but that is error prone since you have to point to the maintenance volume and I don't want JR. people doing this. One other work around is after the logical copy fails, you can run it again as physical since the dataset is enlarged on the first try, but just fails in scratch. BTW, "CATALOG" is never used in this copy since the datasets are indirectly catalogged. Now for the RFE main part of the RFE text: --- Putting maintenance onto a "target" / maintenance sysres volume or set has been an MVS concept and cloning an IPLable sysres set (or swapping IPL sets) "forever" . Many shops also put other IBM products or ISV products on a secondary / tertiary sysres and indirectly catalog them so they are on the sysres set. This is the only way to support rolling IPLs in a sysplex so there are not application outages (another MVS concept). Since those secondary / tertiary volumes are a combination of products, adding new datasets is done via logical copy of a product's target libraries to the target / maintenance sysres and those datasets are indirectly catalogged using a system symbol like , , etc. The copy to the "target" system (maintenance sysres) works fine even if the same named dataset is in use on the live sysres set (be it in the LNKLST, TSO PROC, STC STEPLIB etc.). EXCEPT... when the dataset needs to be enlarged as part of the copy process. In that case you get message ADR497E RC 102 Reason code FP-007 and "ERROR OCCURRED WHILE DELETING UNCATALOGED DATA SET" and the copy for that dataset fails. However, the dataset to be "overlaid" (if you will), is not the dataset in use so DFDSS should have the ability to enlarge it and do the copy. The only solution is to use the DFSMS special SAF authority to rename a dataset in use (STGADMIN.DPDSRN.dsn_to_rename) to rename the "target" dataset on the maintenance volume, then delete it, then rerun the copy job. This could be very error prone if someone doesn't put in the correct volser on ISPF and they could rename the "real" in use dataset or perhaps one on a different sysres set. --- Please vote this one up! Best Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DFDSS RFE - Please read / vote
Hi all, Please read / vote for this RFE. "Provide abilty for DSS to be able to scratch and reallocate an in use data set name that is not the actual dataset in use during a logical copy operation" https://ideas.ibm.com/ideas/ZOS-I-3862 I think you vote here: https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3862 I was honestly shocked this is not supported in DFDSS. I've been using FDR for over 30 years for this. I don't know if you can see the entire text, so I will copy it below to explain the issue, but in summary: If you are copying a dataset to a maintenance sysres (target sysres that will be cloned) and that DSN is ENQd, the copy will work - unless the dataset needs to be scratched / reallocated because the input dataset is larger than the output one that already exists. I've been supporting clients for 30 years that keep ISV (and IBM non-OS) products as an extension of the sysres and recently ran into this at a client that dumped FDR since they had DFDSS and ran into this problem. If you know a way around the issue - shoot! IBM says it is not supported. You can delete the not in use dataset after rename (if allowed) but that is error prone since you have to point to the maintenance volume and I don't want JR. people doing this. One other work around is after the logical copy fails, you can run it again as physical since the dataset is enlarged on the first try, but just fails in scratch. BTW, "CATALOG" is never used in this copy since the datasets are indirectly catalogged. Now for the RFE main part of the RFE text: --- Putting maintenance onto a "target" / maintenance sysres volume or set has been an MVS concept and cloning an IPLable sysres set (or swapping IPL sets) "forever" . Many shops also put other IBM products or ISV products on a secondary / tertiary sysres and indirectly catalog them so they are on the sysres set. This is the only way to support rolling IPLs in a sysplex so there are not application outages (another MVS concept). Since those secondary / tertiary volumes are a combination of products, adding new datasets is done via logical copy of a product's target libraries to the target / maintenance sysres and those datasets are indirectly catalogged using a system symbol like , , etc. The copy to the "target" system (maintenance sysres) works fine even if the same named dataset is in use on the live sysres set (be it in the LNKLST, TSO PROC, STC STEPLIB etc.). EXCEPT... when the dataset needs to be enlarged as part of the copy process. In that case you get message ADR497E RC 102 Reason code FP-007 and "ERROR OCCURRED WHILE DELETING UNCATALOGED DATA SET" and the copy for that dataset fails. However, the dataset to be "overlaid" (if you will), is not the dataset in use so DFDSS should have the ability to enlarge it and do the copy. The only solution is to use the DFSMS special SAF authority to rename a dataset in use (STGADMIN.DPDSRN.dsn_to_rename) to rename the "target" dataset on the maintenance volume, then delete it, then rerun the copy job. This could be very error prone if someone doesn't put in the correct volser on ISPF and they could rename the "real" in use dataset or perhaps one on a different sysres set. --- Please vote this one up! Best Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
