No you can't do a block recall. CLIST/REXX/XDC are your friends. Get listing of dataset to a file, Massage the file to generate the appropriate HRECALL commands Execute the massaged file.
Redefine of the GDG is not necessary. ALTER 'gdgbase' SCRATCH will take care of that for you. Depending on the situation, dfSMS has the constructs to keep the data for 7 years (a "Rolled Off GDS") while still maintain the most recent(up to 255) generations in the catalog. As of z/OS 2.2, the GDS limit has been increased. I forget the new limit, but it is considerably higher than 255. So, if dfSMS is available for this process, you need to simply generate the appropriate MGMTCLAS definitions and issue ALTER 'dsn' MGMTCLAS(newmtgmtclas). dfSMS/dfHSM will do the rest of the cleanup for you. I believe (without knowing) that FDR has the same capabilities. If dfSMS cannot be applied to the situation, there is a lot of tedious work to be done. HTH, <snip> 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. </snip> ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ---------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
