Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
z/OS Master/User catalog dataset re-organization
124 views
Skip to first unread message
suresh chacko
May 24, 2016, 3:28:58 PM5/24/16
to
Hello Group,
Like to know the best practices in z/OS Catalog dataset management and what
all are the steps involved in z/OS catalog dataset re-organization activity.
Kindly share from your expert experience and knowledge.
Regards,
Suresh N C
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
Like to know the best practices in z/OS Catalog dataset management and what
all are the steps involved in z/OS catalog dataset re-organization activity.
Kindly share from your expert experience and knowledge.
Regards,
Suresh N C
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
Gibney, Dave
May 24, 2016, 3:33:07 PM5/24/16
to
1. Buy a tool. Dino, or CR+, or ....
Or
2. At a very quiet time: a. Discconnect the catalog. b. back it up via repro. c. delete and defining it bigger. d. repopulate. e. import.
And it would be a good idea to IPL here.
Or
2. At a very quiet time: a. Discconnect the catalog. b. back it up via repro. c. delete and defining it bigger. d. repopulate. e. import.
And it would be a good idea to IPL here.
suresh chacko
May 24, 2016, 4:31:07 PM5/24/16
to
Hi Dave
Thank you,
Some thoughts...
a. If we have an online application which switches its log datasets every 2
to 3 minutes, how we can manage the disconnect of catalog? Will it lead to
an allocation failure? In this situation how we can avoid an allocation
failure, what is the solution?
b. Repro backup - understood.
c. Delete and Define - In this step, is it better to use a new large
dataset or delete and define the same as bigger?
d. Populate - Is this is done by Import? If not kindly explain.
Are steps of Examine and diagnose required?
Best regards,
Suresh
--
*SureshNc*
Thank you,
Some thoughts...
a. If we have an online application which switches its log datasets every 2
to 3 minutes, how we can manage the disconnect of catalog? Will it lead to
an allocation failure? In this situation how we can avoid an allocation
failure, what is the solution?
b. Repro backup - understood.
c. Delete and Define - In this step, is it better to use a new large
dataset or delete and define the same as bigger?
d. Populate - Is this is done by Import? If not kindly explain.
Are steps of Examine and diagnose required?
Best regards,
Suresh
*SureshNc*
Gibney, Dave
May 24, 2016, 4:36:56 PM5/24/16
to
See inline below.
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU]
> On Behalf Of suresh chacko
> Sent: Tuesday, May 24, 2016 1:31 PM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: z/OS Master/User catalog dataset re-organization
>
> Hi Dave
>
> Thank you,
>
> Some thoughts...
>
> a. If we have an online application which switches its log datasets every 2 to 3
> minutes, how we can manage the disconnect of catalog? Will it lead to an
> allocation failure? In this situation how we can avoid an allocation failure,
> what is the solution?
>
I wouldn't count on or risk it. By quiet, I mean shortly before an IPL with most everything shutdown.
You could try to define a new user catalog. REPRO MERGECAT and DELETE/DEFINE the ALIAS(s). Still very likely to take more time than you have.
> b. Repro backup - understood.
>
> c. Delete and Define - In this step, is it better to use a new large dataset or
> delete and define the same as bigger?
Either or. I'd keep the same name if it was me
>
> d. Populate - Is this is done by Import? If not kindly explain.
Repro back in
>
> Are steps of Examine and diagnose required?
If it's already broken, yes.
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU]
> On Behalf Of suresh chacko
> Sent: Tuesday, May 24, 2016 1:31 PM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: z/OS Master/User catalog dataset re-organization
>
> Hi Dave
>
> Thank you,
>
> Some thoughts...
>
> a. If we have an online application which switches its log datasets every 2 to 3
> minutes, how we can manage the disconnect of catalog? Will it lead to an
> allocation failure? In this situation how we can avoid an allocation failure,
> what is the solution?
>
You could try to define a new user catalog. REPRO MERGECAT and DELETE/DEFINE the ALIAS(s). Still very likely to take more time than you have.
> b. Repro backup - understood.
>
> c. Delete and Define - In this step, is it better to use a new large dataset or
> delete and define the same as bigger?
>
> d. Populate - Is this is done by Import? If not kindly explain.
>
> Are steps of Examine and diagnose required?
suresh chacko
May 24, 2016, 4:43:55 PM5/24/16
to
Dear Dave,
Thank you so much for the share.
Have a great day!
Regards,
Suresh
Thank you so much for the share.
Have a great day!
Regards,
Suresh
John Eells
May 24, 2016, 4:49:35 PM5/24/16
to
suresh chacko wrote:
> Hello Group,
>
> Like to know the best practices in z/OS Catalog dataset management and what
> all are the steps involved in z/OS catalog dataset re-organization activity.
<snip>
> Hello Group,
>
> Like to know the best practices in z/OS Catalog dataset management and what
> all are the steps involved in z/OS catalog dataset re-organization activity.
My view is this:
The master catalog should "never" need to be reorganized. It's nearly
static compared to user catalogs, and if you have the right stuff in
there all of it should be cached anyway once the system is up and
running. (See z/OS DFSMS Managing Catalogs for the recommendations
about the content of the master catalog.)
User catalogs should be reorganized, *if necessary*, one last time and
then enabled for CA Reclaim like (nearly) any other KSDS. After that,
let them manage themselves...
--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com
retired mainframer
May 24, 2016, 4:51:33 PM5/24/16
to
There really is no generic best practice. Your catalog management should be based on the needs of your particular installation. A data center handling corporate administration is different than a development center generating products for sale which is different than a service bureau with multiple customers who expect zero cross-talk.
The most common rule of thumb I have heard is "limit the master catalog to system datasets." But there are different interpretations of which datasets are really system ones. Some include IBM program products, others don't. Some include vendor products, others don't. Some have a different catalog for each vendor, others have a common one for all vendors. You get to decide.
After you have decided how you want to organize your catalogs, the Managing Catalogs manual would be a good place to start. And then people here can assist if you have detailed questions about how to perform some task.
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
> Behalf Of suresh chacko
> Sent: Tuesday, May 24, 2016 12:29 PM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: z/OS Master/User catalog dataset re-organization
>
The most common rule of thumb I have heard is "limit the master catalog to system datasets." But there are different interpretations of which datasets are really system ones. Some include IBM program products, others don't. Some include vendor products, others don't. Some have a different catalog for each vendor, others have a common one for all vendors. You get to decide.
After you have decided how you want to organize your catalogs, the Managing Catalogs manual would be a good place to start. And then people here can assist if you have detailed questions about how to perform some task.
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
> Behalf Of suresh chacko
> Sent: Tuesday, May 24, 2016 12:29 PM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: z/OS Master/User catalog dataset re-organization
>
> Hello Group,
>
> Like to know the best practices in z/OS Catalog dataset management and what
> all are the steps involved in z/OS catalog dataset re-organization activity.
>
> Kindly share from your expert experience and knowledge.
>
> Like to know the best practices in z/OS Catalog dataset management and what
> all are the steps involved in z/OS catalog dataset re-organization activity.
>
> Kindly share from your expert experience and knowledge.
Gibney, Dave
May 24, 2016, 4:55:59 PM5/24/16
to
> Subject: Re: z/OS Master/User catalog dataset re-organization
>
> suresh chacko wrote:
> > Hello Group,
> >
> > Like to know the best practices in z/OS Catalog dataset management and
> > what all are the steps involved in z/OS catalog dataset re-organization
> activity.
> <snip>
>
> My view is this:
>
> The master catalog should "never" need to be reorganized. It's nearly static
> compared to user catalogs, and if you have the right stuff in there all of it
> should be cached anyway once the system is up and running. (See z/OS
> DFSMS Managing Catalogs for the recommendations about the content of the
> master catalog.)
>
> User catalogs should be reorganized, *if necessary*, one last time and then
> enabled for CA Reclaim like (nearly) any other KSDS. After that, let them
> manage themselves...
I did assume that 1. He was talking about a user catalog. And 2. He was asking because warnings or errors are occurring already.
>
> suresh chacko wrote:
> > Hello Group,
> >
> > Like to know the best practices in z/OS Catalog dataset management and
> > what all are the steps involved in z/OS catalog dataset re-organization
> activity.
> <snip>
>
> My view is this:
>
> The master catalog should "never" need to be reorganized. It's nearly static
> compared to user catalogs, and if you have the right stuff in there all of it
> should be cached anyway once the system is up and running. (See z/OS
> DFSMS Managing Catalogs for the recommendations about the content of the
> master catalog.)
>
> User catalogs should be reorganized, *if necessary*, one last time and then
> enabled for CA Reclaim like (nearly) any other KSDS. After that, let them
> manage themselves...
I didn't mention that the tool vendors will sometimes provide a free trial for such occasions. :)
suresh chacko
May 24, 2016, 11:00:05 PM5/24/16
to
Hi all,
Thanks to all for the valuable inputs and shares.
Is it required to organize a planned outage during the user catalog
re-organization or move? If so, how we can avoid an outage during this
activity in an online shop where we have 2 systems of which one is at DR
site on which all the LPARS are spread across and connected with GRS.
Regards,
Suresh
--
*SureshNc*
Thanks to all for the valuable inputs and shares.
Is it required to organize a planned outage during the user catalog
re-organization or move? If so, how we can avoid an outage during this
activity in an online shop where we have 2 systems of which one is at DR
site on which all the LPARS are spread across and connected with GRS.
Regards,
Suresh
*SureshNc*
wjip...@gmail.com
May 25, 2016, 3:36:05 AM5/25/16
to
I support John's recommendations. By the way, are you sure that you really need to reorganize that catalog? You should only do that if it is reaching the max number of extents, or the volume is running full.
But in your case you might be able to go to a new empty catalog. When the log is switched I assume it means that a new unique dataset is created. That being the case you might be able to get away with:
- create a new catalog
- redefine the alias to point to the new catalog immediately after a switch. new datasets will be defined here. old datasets will not be available.
- repro-mergecat old datasets from the old to the new catalog.
I hope someone will tell us if it is a bad idea.
But be very very careful and do it when the possible impact of an outage is smallest. And test beforehand.
Willy
But in your case you might be able to go to a new empty catalog. When the log is switched I assume it means that a new unique dataset is created. That being the case you might be able to get away with:
- create a new catalog
- redefine the alias to point to the new catalog immediately after a switch. new datasets will be defined here. old datasets will not be available.
- repro-mergecat old datasets from the old to the new catalog.
I hope someone will tell us if it is a bad idea.
But be very very careful and do it when the possible impact of an outage is smallest. And test beforehand.
Willy
Mike Schwab
May 25, 2016, 10:21:04 AM5/25/16
to
You only have to take down the applications using the datasets in the
affected catalog.
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
affected catalog.
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
Larry Crilley
May 25, 2016, 11:14:33 AM5/25/16
to
Someone mentioned a few tools earlier in this email chain. I believe they all support reorganizing a catalog without the need for an outage. I know the T-REX tool from Dino-Software supports it. You can even move the catalog to another volume, if you choose. Without the tool, you will certainly need a time-slice where no one is accessing the catalog.
wjip...@gmail.com
May 25, 2016, 2:21:50 PM5/25/16
to
In my experience you do not necessarily have to stop the applications. It mostly has to do do with the dataset types involved. VSAM I would stop the application if possible, sequential or PO not necessarily.
Willy
Willy
suresh chacko
May 26, 2016, 12:48:12 AM5/26/16
to
Hi all,
Thanks to all.
Gone through z/OS catalog management reference guide too.
Best regards,
Suresh
Thanks to all.
Gone through z/OS catalog management reference guide too.
Best regards,
Suresh
0 new messages