Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[George, William@FTB]

Thanks and I've already rewritten it to use the CSI!  8-D

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Gould
Sent: Tuesday, December 27, 2016 1:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

> On Dec 27, 2016, at 10:59 AM, George, William@FTB  
> wrote:
> 
> I found parsing the LISTCAT output easy as I've done it many times and 
> much easier to understand.  8-D However. I just found the IBM REXX sample for 
> CSI and got it working.
> I'll copy the REXX I have using the LISTCAT code and change it to use CSI and 
> then compare the two.
> Thanks!
> 
> Bill

Bill,

Be aware that the list cat output *DOES* change and there is no warning from 
IBM.

Years ago someone bought a cheap listcat at a company I worked for (it was 
written in COBOL no less).
Once a year (or so it seemed) the utility would break. I would look at the 
source (they provided) and waste 1 or 2 hours of my time trying to debug it.
It was just not worth the $25.
Use the way Tom M suggested and it will eliminate 3AM calls.

Ed
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

__
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[Edward Gould]

> On Dec 27, 2016, at 10:59 AM, George, William@FTB  
> wrote:
> 
> I found parsing the LISTCAT output easy as I've done it many times and much 
> easier to understand.  8-D
> However. I just found the IBM REXX sample for CSI and got it working.
> I'll copy the REXX I have using the LISTCAT code and change it to use CSI and 
> then compare the two.
> Thanks!
> 
> Bill

Bill,

Be aware that the list cat output *DOES* change and there is no warning from 
IBM.

Years ago someone bought a cheap listcat at a company I worked for (it was 
written in COBOL no less).
Once a year (or so it seemed) the utility would break. I would look at the 
source (they provided) and waste 1 or 2 hours of my time trying to debug it.
It was just not worth the $25.
Use the way Tom M suggested and it will eliminate 3AM calls.

Ed
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[Dana Mitchell]

Yes there's an excellent REXX example in SYS1.SAMPLIB(IGGCSIRX) that can easily 
be modified to do all sorts of cool things (along with a few assembler samples 
too).

Dana

On Tue, 27 Dec 2016 16:59:08 +, George, William@FTB 
 wrote:
 
However. I just found the IBM REXX sample for CSI and got it working. 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[Bill Woodger]

As came up in a recent discussion here (Lizette's small COBOL program thing), 
IBM's recommendation is to use CSI over parsing LISTCAT. LISTCAT output is, and 
has been for a while, open to change, even a breaking change, and we've been 
warned.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[George, William@FTB]

I found parsing the LISTCAT output easy as I've done it many times and much 
easier to understand.  8-D
However. I just found the IBM REXX sample for CSI and got it working.
I'll copy the REXX I have using the LISTCAT code and change it to use CSI and 
then compare the two.
Thanks!

Bill

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, December 27, 2016 8:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

On Tue, 27 Dec 2016 16:30:32 +, George, William@FTB wrote about IGGCSI00:

>I've never had success trying it. The one example I have I could not 
>get to work but it has been a couple of years since then.

I've only used it once, and don't remember having any trouble with it. 
Certainly easier than parsing LISTCAT output.

--
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

__
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[Tom Marchant]

On Tue, 27 Dec 2016 16:30:32 +, George, William@FTB wrote 
about IGGCSI00:

>I've never had success trying it. The one example I have I could 
>not get to work but it has been a couple of years since then. 

I've only used it once, and don't remember having any trouble with it. 
Certainly easier than parsing LISTCAT output.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[George, William@FTB]

I've never had success trying it. The one example I have I could not get to 
work but it has been a couple of years since then. 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, December 27, 2016 6:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

On Tue, 20 Dec 2016 12:25:30 -0700, Sri h Kolusu wrote:

>Step 1 : Get Listcat information for the GDG Base Step 2 : parse the 
>Listcat information for the migrated generations and

Why not use the Catalog Search Interface (IGGCSI00) rather than parse a LISTCAT 
report? It is easier and more efficient.

--
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

__
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[Tom Marchant]

On Tue, 20 Dec 2016 12:25:30 -0700, Sri h Kolusu wrote:

>Step 1 : Get Listcat information for the GDG Base
>Step 2 : parse the Listcat information for the migrated generations and 

Why not use the Catalog Search Interface (IGGCSI00) rather than 
parse a LISTCAT report? It is easier and more efficient.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[Lizette Koehler]

Just as a side note - created on 15 Apr 2015

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_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:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of George, William@FTB
> Sent: Wednesday, December 21, 2016 9:18 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mick Graley
> Sent: Tuesday, December 20, 2016 5:17 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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 
> 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:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of George, William@FTB
> > Sent: Tuesday, December 20, 2016 11:04 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > 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 

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[George, William@FTB]

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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mick Graley
Sent: Tuesday, December 20, 2016 5:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
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 
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:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of George, William@FTB
> Sent: Tuesday, December 20, 2016 11:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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 MM 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, 

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[Mick Graley]

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 
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:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of George, William@FTB
> Sent: Tuesday, December 20, 2016 11:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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 MM 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 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
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[Dana Mitchell]

FDRReport is able to select file entries with great precision and produce 
control cards to do such a task easily.  It's been a handful of years since 
I've worked with FDR, but I found IDP support to be very helpful and 
knowledgeable,  and able to provide me with an FDRREPORT solution to fix my 
problems such as this.

Dana  

On Tue, 20 Dec 2016 21:13:22 +, George, William@FTB 
 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
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[George, William@FTB]

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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of George, William@FTB
Sent: Tuesday, December 20, 2016 11:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
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 MM 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 
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: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[Steve Smith]

An EXTENDED GDG can have 999 generations active.  I believe that a GDG must
be defined as EXTENDED, it isn't ALTERable.

One thing to keep in mind is that with an EXTENDED GDG, each generation has
its own catalog entry.  That could cause a significant catalog size
increase.  I don't know why it was implemented this way.

sas

On Tue, Dec 20, 2016 at 2:33 PM, Allan Staller 
wrote:

> What  Sri said!
>
> 
>
> Step 1 : Get Listcat information for the GDG Base Step 2 : parse the
> Listcat information for the migrated generations and generate HRECALL
> commands using DFSORT
> Step3  : Run the commands from step 2
>
> //***
> //* GET THE LIST OF DATASETS NAMES USING LISTCAT ON GDG BASE*
> //***
> //STEP0100 EXEC PGM=IKJEFT01
> //SYSTSPRT DD DSN=&,DISP=(,PASS),SPACE=(CYL,(25,25),RLSE),
> //DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920)
> //SYSTSIN  DD *
>   LISTCAT LEVEL('Your GDG Base Name') ALL
> //*
> //***
> //* PARSE THE LISTCAT INFO TO GENERATE THE HRECALL STATEMENTS   *
> //***
> //STEP0200 EXEC PGM=SORT
> //SYSOUT   DD SYSOUT=*
> //SORTIN   DD DISP=SHR,DSN=&
> //SORTOUT  DD DSN=&,DISP=(,PASS),SPACE=(CYL,(25,25),RLSE),
> //DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920)
> //SORTOUT  DD SYSOUT=*
> //SYSINDD *
>   OPTION COPY
>   INREC IFTHEN=(WHEN=GROUP,BEGIN=(1,7,CH,EQ,C'NONVSAM'),
> PUSH=(82:17,44)),
>   IFTHEN=(WHEN=(8,6,CH,EQ,C'VOLSER',AND,26,5,CH,EQ,C'MIGRAT'),
>   OVERLAY=(81:C'P'))
>
>   OUTFIL INCLUDE=(81,1,CH,EQ,C'P'),
> BUILD=(82,44,JFY=(SHIFT=LEFT,LEAD=C'  HRECALL ''',
>   TRAIL=C''' NOWAIT',LENGTH=80))
> //*
> //
> //* RUN THE HRECALL COMMANDS *
> //
> //STEP0300 EXEC PGM=IKJEFT01
> //SYSTSPRT DD SYSOUT=*
> //SYSTSIN  DD DISP=SHR,DSN=&
> //*
> 
>
>
> ::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 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: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[Allan Staller]

What  Sri said!



Step 1 : Get Listcat information for the GDG Base Step 2 : parse the Listcat 
information for the migrated generations and generate HRECALL commands using 
DFSORT
Step3  : Run the commands from step 2

//***
//* GET THE LIST OF DATASETS NAMES USING LISTCAT ON GDG BASE*
//***
//STEP0100 EXEC PGM=IKJEFT01
//SYSTSPRT DD DSN=&,DISP=(,PASS),SPACE=(CYL,(25,25),RLSE), 
//DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920) 
//SYSTSIN  DD *
  LISTCAT LEVEL('Your GDG Base Name') ALL
//*
//***
//* PARSE THE LISTCAT INFO TO GENERATE THE HRECALL STATEMENTS   *
//***
//STEP0200 EXEC PGM=SORT 
//SYSOUT   DD SYSOUT=* 
//SORTIN   DD DISP=SHR,DSN=& 
//SORTOUT  DD DSN=&,DISP=(,PASS),SPACE=(CYL,(25,25),RLSE), 
//DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920) 
//SORTOUT  DD SYSOUT=* 
//SYSINDD * 
  OPTION COPY
  INREC IFTHEN=(WHEN=GROUP,BEGIN=(1,7,CH,EQ,C'NONVSAM'), 
PUSH=(82:17,44)),
  IFTHEN=(WHEN=(8,6,CH,EQ,C'VOLSER',AND,26,5,CH,EQ,C'MIGRAT'),
  OVERLAY=(81:C'P')) 
 
  OUTFIL INCLUDE=(81,1,CH,EQ,C'P'), 
BUILD=(82,44,JFY=(SHIFT=LEFT,LEAD=C'  HRECALL ''', 
  TRAIL=C''' NOWAIT',LENGTH=80))
//*
//
//* RUN THE HRECALL COMMANDS *
//
//STEP0300 EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD DISP=SHR,DSN=&
//* 



::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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[Allan Staller]

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,


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 MM 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.



::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 lists...@listserv.ua.edu 

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[PINION, RICHARD W.]

You mentioned FDR as the DASD management software.  You could use FDREPORT to
select the GDG's in question, and then have FDREPORT generate the appropriate
control statements.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sri h Kolusu
Sent: Tuesday, December 20, 2016 2:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

Bill,

Step 1 : Get Listcat information for the GDG Base Step 2 : parse the Listcat 
information for the migrated generations and generate HRECALL commands using 
DFSORT
Step3  : Run the commands from step 2

//***
//* GET THE LIST OF DATASETS NAMES USING LISTCAT ON GDG BASE*
//***
//STEP0100 EXEC PGM=IKJEFT01
//SYSTSPRT DD DSN=&,DISP=(,PASS),SPACE=(CYL,(25,25),RLSE), 
//DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920) 
//SYSTSIN  DD *
  LISTCAT LEVEL('Your GDG Base Name') ALL
//*
//***
//* PARSE THE LISTCAT INFO TO GENERATE THE HRECALL STATEMENTS   *
//***
//STEP0200 EXEC PGM=SORT 
//SYSOUT   DD SYSOUT=* 
//SORTIN   DD DISP=SHR,DSN=& 
//SORTOUT  DD DSN=&,DISP=(,PASS),SPACE=(CYL,(25,25),RLSE), 
//DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920) 
//SORTOUT  DD SYSOUT=* 
//SYSINDD * 
  OPTION COPY
  INREC IFTHEN=(WHEN=GROUP,BEGIN=(1,7,CH,EQ,C'NONVSAM'), 
PUSH=(82:17,44)),
  IFTHEN=(WHEN=(8,6,CH,EQ,C'VOLSER',AND,26,5,CH,EQ,C'MIGRAT'),
  OVERLAY=(81:C'P')) 
 
  OUTFIL INCLUDE=(81,1,CH,EQ,C'P'), 
BUILD=(82,44,JFY=(SHIFT=LEFT,LEAD=C'  HRECALL ''', 
  TRAIL=C''' NOWAIT',LENGTH=80))
//*
//
//* RUN THE HRECALL COMMANDS *
//
//STEP0300 EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD DISP=SHR,DSN=&
//* 

Thanks,
Kolusu
DFSORT Development
IBM Corporation

IBM Mainframe Discussion List  wrote on
12/20/2016 12:03:46 PM:

> From: "George, William@FTB" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 12/20/2016 12:04 PM
> Subject: A Means To RECALL Migrated GDS' Based on a Block of Relative
Gens
> Sent by: IBM Mainframe Discussion List 
> 
> 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 MM 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 

Re: A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[Sri h Kolusu]

Bill,

Step 1 : Get Listcat information for the GDG Base
Step 2 : parse the Listcat information for the migrated generations and 
generate HRECALL commands using DFSORT
Step3  : Run the commands from step 2

//***
//* GET THE LIST OF DATASETS NAMES USING LISTCAT ON GDG BASE*
//***
//STEP0100 EXEC PGM=IKJEFT01 
//SYSTSPRT DD DSN=&,DISP=(,PASS),SPACE=(CYL,(25,25),RLSE), 
//DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920) 
//SYSTSIN  DD * 
  LISTCAT LEVEL('Your GDG Base Name') ALL
//* 
//***
//* PARSE THE LISTCAT INFO TO GENERATE THE HRECALL STATEMENTS   *
//***
//STEP0200 EXEC PGM=SORT 
//SYSOUT   DD SYSOUT=* 
//SORTIN   DD DISP=SHR,DSN=& 
//SORTOUT  DD DSN=&,DISP=(,PASS),SPACE=(CYL,(25,25),RLSE), 
//DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920) 
//SORTOUT  DD SYSOUT=* 
//SYSINDD * 
  OPTION COPY 
  INREC IFTHEN=(WHEN=GROUP,BEGIN=(1,7,CH,EQ,C'NONVSAM'), 
PUSH=(82:17,44)), 
  IFTHEN=(WHEN=(8,6,CH,EQ,C'VOLSER',AND,26,5,CH,EQ,C'MIGRAT'), 
  OVERLAY=(81:C'P')) 
 
  OUTFIL INCLUDE=(81,1,CH,EQ,C'P'), 
BUILD=(82,44,JFY=(SHIFT=LEFT,LEAD=C'  HRECALL ''', 
  TRAIL=C''' NOWAIT',LENGTH=80)) 
//* 
//
//* RUN THE HRECALL COMMANDS *
//
//STEP0300 EXEC PGM=IKJEFT01 
//SYSTSPRT DD SYSOUT=* 
//SYSTSIN  DD DISP=SHR,DSN=& 
//* 

Thanks,
Kolusu
DFSORT Development
IBM Corporation

IBM Mainframe Discussion List  wrote on 
12/20/2016 12:03:46 PM:

> From: "George, William@FTB" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 12/20/2016 12:04 PM
> Subject: A Means To RECALL Migrated GDS' Based on a Block of Relative 
Gens
> Sent by: IBM Mainframe Discussion List 
> 
> 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 MM 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 

A Means To RECALL Migrated GDS' Based on a Block of Relative Gens

[George, William@FTB]

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 MM 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN