It's also worth noting that you can use wild cards in the HRECALL data set name if you can be that generic, i.e. bring back ALL migrated generations with a single HRECALL command. I use it a lot to recall all my personal code libraries before I go on overnight call-out - I hate waiting for data set recalls when I'm trying to fix things in the early hours of the morning! Cheers, Mick.
On 20 December 2016 at 21:13, George, William@FTB <[email protected]> wrote: > Thanks all. At this point it looks like Sri's LISTCAT/SORT/RECALL or a > REXX exec to do all the similar steps in one. > The Extended GDG I believe would be overkill in terms of catalogued > datasets. > > Bill > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of George, William@FTB > Sent: Tuesday, December 20, 2016 11:04 AM > To: [email protected] > Subject: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens > > Bottom Line: I am looking for a means to RECALL a block of migrated GDS > (GDG generation datasets) from the previous month via a monthly task. > > BACKGROUND > First, I'm in applications not systems. > Second, we are changing our storage management system where we must now > define (and redefine existing) GDG's with SCRATCH. Most were unfortunately > defined with NOSCRATCH so there are a boatload of uncatalogued dataset on > the system for those that fell out of the GDG's LIMIT parm. .Plus, our > current FDR storage management system archives all the GDS' long before > they would even drop off the LIMIT, but that is beside the point here other > than setting the LIMIT really didn't have much priority because of this.. > The point is our GDS are archived and are always available even GDS dropped > off the LIMIT YEARS ago. This allowed us to go as far back a necessary to > research issues. Now times are changing and Storage management, rightly so, > wants to clean up all the uncatalogued datasets and fix this situation.. > With the new system coming in the automatic FDR archiving of generation > datasets is going away and as mentioned above, GDGs are to be defined with > SCRATCH. Because of the SCRATCH option where GDS' are deleted when dropped > off via the LIMIT we will need to reassess the LIMIT option on them to > allow for proper data recovery and research considerations. We frequently > get requests to look back at old data for various reasons. > > Our main concern are the GDS' allocated daily as we are required to have > seven years of data available. We will update all pertinent daily GDGs to > the max LIMIT of 255. However, this only is 'about' one year's worth of > data. We have some 500+ daily GDGs that have generations allocated. So > backup/archiving of these is a necessity. > > ISSUE: > The current plan is to run a month's end job to backup/archive all of the > previous month's daily GDS into several ADRDSSU dump datasets with a naming > convention that indicates what YYYYMM of data is contained within. > However, ADRDSSU will not pick up any dataset in a MIGRAT status. So these > must be RECALL'ed prior to the dump. > > QUESTION: > Is there a means to call in, or do a HRECALL on a block of GDS? For > example Gens -0 thru -31 without out having to code each gen separately? > Of course gens 0 thru about -7 will probably not be migrated at this point > but you get the idea... hopefully. > I can certainly do this with a REXX exec doing a HRECALL on each needed > but would like to avoid that if possible. > > Any insights would be appreciated. > > Thanks! > Bill > > ______________________________________________________________________ > CONFIDENTIALITY NOTICE: This email from the State of California is for the > sole use of the intended recipient and may contain confidential and > privileged information. Any unauthorized review or use, including > disclosure or distribution, is prohibited. If you are not the intended > recipient, please contact the sender and destroy all copies of this email. > > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
