Re: GDG Cleanup
Emeffers, Below is some JCL I use to clean up data sets that have a repeatable naming pattern. It is usually a mass delete of 1000s of data sets. Being a lab, I use the NSCR step because sometimes the volumes have been blown away without cleaning up the data sets first. Also good for deleting a years worth of SMF data sets. //PERFDEL$ JOB (ACCT#),'STGADM1',CLASS=H,MSGCLASS=X,MSGLEVEL=(1,1), // NOTIFY=&SYSUID //*** //* QUICK DELETE OF FILES USING A MASK //*** //DEL EXEC PGM=IDCAMS,REGION=6M //SYSPRINT DD SYSOUT=* //SYSINDD * DELETE RAID800.E*.B*.U0*.C* MASK PURGE /* //*** //* QUICK UNCATALOG OF FILES USING A MASK //*** //DELNSCR EXEC PGM=IDCAMS,REGION=6M //SYSPRINT DD SYSOUT=* //SYSINDD * DELETE RAID800.E*.B*.U0*.C* MASK PURGE NSCR /* You can achieve similar results with DFSMSdss dump and delete of data sets to a dummy output, using filters. I just find this method cleaner when I have a lot of missing data sets. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Mingee Sent: Monday, February 5, 2018 9:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] GDG Cleanup I intended to specify this cleanup is for DISK GDG files. Old unused files can be left when an application is retired or a dsn is changed or when a tape gdg with NSCR is changed to DISK file. Also, there is an TMS Utility - TMSOSCAT that will fix tapes that have been uncat'd put are not eligible for SCRATCH and those that have been TMS SCRATCHED but are still Catalogued. I think if a new disk GDG has not been created in over a year, it is almost certain a new gen will not be created today or tomorrow. I successfully completed this task at two different sites. The only error or problem was one job created a file dsn equal to the GDG BASE, but the jcl did not use (+1), so when I deleted the GDG's and the BASE GDG this job failed. Each site had over 100K files deleted and 100 to 200 3390-3 disk freed up and these were no longer backed up in the weekly backup jobs. Not a bad savings for those who are interested, have the time, and permission. -Original Message- From: IBM Mainframe Discussion List [ <mailto:IBM-MAIN@LISTSERV.UA.EDU> mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Smith Sent: Monday, February 05, 2018 10:52 AM To: <mailto:IBM-MAIN@LISTSERV.UA.EDU> IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GDG Cleanup lol, I guess the OP may have accidentally sent this advice to the wrong address. Rocket CR+ would make this easier However, you would in general hope that GDGs are defined to satisfy actual requirements, and not pile up garbage indefinitely. sas On Mon, Feb 5, 2018 at 7:13 AM, John McKown < <mailto:john.archie.mck...@gmail.com> john.archie.mck...@gmail.com> wrote: > On Sun, Feb 4, 2018 at 11:55 PM, David Mingee < <mailto:ming...@prodigy.net> > ming...@prodigy.net> wrote: > > > For those who might have the time or inclination, I suggest running > > a LISTC for your GDG's and then SORT the output file by LAST ALTER > > DATE. Then consider deleting all of them that are older than one > > year old. You may find 1000's of these for various reasons. Also, > > you could run IEHLIST and find old gdg files that were mistakenly > > set to NOSCRATCH and then delete them. > > > > > Well, just speaking for my shop, one year is way too short. We create > annual tapes for end-of-year data. And we often need them going back > 10 years. Actuarial people love historical data. Some financial people > do too. > > > -- > I have a theory that it's impossible to prove anything, but I can't > prove it. > > Maranatha! <>< > John McKown > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to <mailto:lists...@
Re: GDG Cleanup
I intended to specify this cleanup is for DISK GDG files. Old unused files can be left when an application is retired or a dsn is changed or when a tape gdg with NSCR is changed to DISK file. Also, there is an TMS Utility - TMSOSCAT that will fix tapes that have been uncat'd put are not eligible for SCRATCH and those that have been TMS SCRATCHED but are still Catalogued. I think if a new disk GDG has not been created in over a year, it is almost certain a new gen will not be created today or tomorrow. I successfully completed this task at two different sites. The only error or problem was one job created a file dsn equal to the GDG BASE, but the jcl did not use (+1), so when I deleted the GDG's and the BASE GDG this job failed. Each site had over 100K files deleted and 100 to 200 3390-3 disk freed up and these were no longer backed up in the weekly backup jobs. Not a bad savings for those who are interested, have the time, and permission. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Smith Sent: Monday, February 05, 2018 10:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GDG Cleanup lol, I guess the OP may have accidentally sent this advice to the wrong address. Rocket CR+ would make this easier However, you would in general hope that GDGs are defined to satisfy actual requirements, and not pile up garbage indefinitely. sas On Mon, Feb 5, 2018 at 7:13 AM, John McKown wrote: > On Sun, Feb 4, 2018 at 11:55 PM, David Mingee wrote: > > > For those who might have the time or inclination, I suggest running > > a LISTC for your GDG's and then SORT the output file by LAST ALTER > > DATE. Then consider deleting all of them that are older than one > > year old. You may find 1000's of these for various reasons. Also, > > you could run IEHLIST and find old gdg files that were mistakenly > > set to NOSCRATCH and then delete them. > > > > > Well, just speaking for my shop, one year is way too short. We create > annual tapes for end-of-year data. And we often need them going back > 10 years. Actuarial people love historical data. Some financial people > do too. > > > -- > I have a theory that it's impossible to prove anything, but I can't > prove it. > > Maranatha! <>< > John McKown > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- sas -- 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: GDG Cleanup
On Mon, Feb 5, 2018 at 9:52 AM, Steve Smith wrote: > lol, I guess the OP may have accidentally sent this advice to the wrong > address. > > Rocket CR+ would make this easier > > However, you would in general hope that GDGs are defined to satisfy actual > requirements, and not pile up garbage indefinitely. > Nah, we pile up GDGs the way that cars pile up on L.A. freeways. Even when we attempt to clean up stuff, we generally get back something like: "We're not sure if that is important or not. Better leave it alone for now." This on data sets which haven't be read since the 1990s. We have virtual tapes which were written by programs which we no longer have and to which we don't have any structure definition. But we keep them "just in case". It's like keeping books written in Linear A Greek - yeah, it may be good information - but it is not usable because nobody can read it. > > sas > > -- I have a theory that it's impossible to prove anything, but I can't prove it. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GDG Cleanup
lol, I guess the OP may have accidentally sent this advice to the wrong address. Rocket CR+ would make this easier However, you would in general hope that GDGs are defined to satisfy actual requirements, and not pile up garbage indefinitely. sas On Mon, Feb 5, 2018 at 7:13 AM, John McKown wrote: > On Sun, Feb 4, 2018 at 11:55 PM, David Mingee wrote: > > > For those who might have the time or inclination, I suggest running > > a LISTC for your GDG's and then SORT the output file by LAST ALTER > > DATE. Then consider deleting all of them that are older than one > > year old. You may find 1000's of these for various reasons. Also, > > you could run IEHLIST and find old gdg files that were mistakenly > > set to NOSCRATCH and then delete them. > > > > > Well, just speaking for my shop, one year is way too short. We create > annual tapes for end-of-year data. And we often need them going back 10 > years. Actuarial people love historical data. Some financial people do > too. > > > -- > I have a theory that it's impossible to prove anything, but I can't prove > it. > > Maranatha! <>< > John McKown > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GDG Cleanup
On Sun, Feb 4, 2018 at 11:55 PM, David Mingee wrote: > For those who might have the time or inclination, I suggest running > a LISTC for your GDG's and then SORT the output file by LAST ALTER > DATE. Then consider deleting all of them that are older than one > year old. You may find 1000's of these for various reasons. Also, > you could run IEHLIST and find old gdg files that were mistakenly > set to NOSCRATCH and then delete them. > > Well, just speaking for my shop, one year is way too short. We create annual tapes for end-of-year data. And we often need them going back 10 years. Actuarial people love historical data. Some financial people do too. -- I have a theory that it's impossible to prove anything, but I can't prove it. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
GDG Cleanup
For those who might have the time or inclination, I suggest running a LISTC for your GDG's and then SORT the output file by LAST ALTER DATE. Then consider deleting all of them that are older than one year old. You may find 1000's of these for various reasons. Also, you could run IEHLIST and find old gdg files that were mistakenly set to NOSCRATCH and then delete them. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
