This is fascinating info. I've always wondered what the Vnn was for. Question though: in an SMS environment, you can't have uncataloged data sets lying around. What happens to the V00 guy?
. . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: "Robert A. Rosenberg" <hal9...@panix.com> To: IBM-MAIN@bama.ua.edu Date: 08/01/2011 12:53 PM Subject: Re: Orphan GDG problem Sent by: IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> At 14:08 +0100 on 08/01/2011, Anstey, Gerry wrote about Orphan GDG problem: >The problem is that I cannot delete the file using HDELETE, or >IDCAMS with NVS, or standard IEFBR14 with an uncatlg NOTE: I see the problem has been solved but for the future here is an alternate method that would have solved the issue. One trick is to create a one track DASD dataset by the name of PGINTT11.B671.TRANSACT.WINS.BKUP.G1460V01. This will remove the PGINTT11.B671.TRANSACT.WINS.BKUP.G1460V00 entry by replacing it. You can then delete the dummy DASD dataset. Note that GDG files of the form GDG.GxxxxVyy (where yy is not 00) will replace a GXxxxxV00 version and will have the same (0) or (-X) relative number as the replaced GxxxxV00 original. This trick is useful when you need to replace a GDG file with an updated version but not break the numbering. There is no need for the Vyy to be higher than the current one just different. Making it equal to the current yy+1 just allows keeping track of how many times you have replaced that version of the generation. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
