Just as a side note - created on 15 Apr 2015 http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=69672
This RFE is to make converting to extended GDGs easier. Feel free to vote for it In z/OS 2.2, support is introduced for GDG's with more than 255 generations. However there's no support to change existing GDG's to the new format, making it highly impractical to move to using them; we would have to delete mission critical GDG's and recreate them, somehow managing to maintain all the generations of the old GDG and get them back into the new extended GDG. This would be a very high-risk procedure for actually losing data. Use case: Need to be able to use the new GDG format for existing GDG's, or the usability for this new format is drastically reduced. Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of George, William@FTB > Sent: Wednesday, December 21, 2016 9:18 AM > To: [email protected] > Subject: Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens > > Mick, I was hoping there might be a sub-set of that in some manner where you > could indicate a block of gens. But I knew even Santa could not bring me such > a nifty command. With some 500+ GDGs that soon each will have a LIMIT of 255. > I don't think bringing back, let's see... 500 * 245 (-10 as they probably have > not migrated as yet) = HECK of a lot of new catalog entries... would not make > our storage group pleased. 8-D > But it was certainly worth noting and I have used that at times. > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Mick Graley > Sent: Tuesday, December 20, 2016 5:17 PM > To: [email protected] > Subject: Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens > > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
