Try here:
http://www-01.ibm.com/support/docview.wss?uid=isg1II13354
snip
I just started receiving the following message on a catalog
IEC361I CATALOG CATLOG.MVS.VGEM913 (DATA) HAS REACHED 82% OF THE MAXIMUM
EXTENTS
The messages are coming out about twice a month.
I am running z/OS 1.9
Can
30, 2012 6:05 AM
:: To: IBM-MAIN@bama.ua.edu
:: Subject: Re: Catalog Question
::
:: Try here:
::
:: http://www-01.ibm.com/support/docview.wss?uid=isg1II13354
::
::
:: snip
:: I just started receiving the following message on a catalog
:: IEC361I CATALOG CATLOG.MVS.VGEM913 (DATA) HAS REACHED 82
I had to do exactly the same thing last night to two of my catalogs, for the
exact same reason.
Here is a copy of the jcl I used.
You will have to come up w/ your correct space values.
In my case, each catalog had 200,000+ entries.
//TUCO JOB (10679),'S6 CAT BIGGER ',
//
Depending on-may be easier to do REPRO MERGECAT.
In a message dated 4/30/2012 3:46:27 P.M. Central Daylight Time,
t...@cio.sc.gov writes:
I had to do exactly the same thing last night to two of my catalogs, for
the exact same reason.
Here is a copy of the jcl I used.
You will have to
W dniu 2010-02-19 17:34, Darth Keller pisze:
[...]
Yes, I need all my applications to be available too and by separating them
into more than one catalog I decrease the likelyhood that 1 broken catalog
impacts all applications.
My point is that if I have my applications separated into different
-- You also want to consider recoverability issues - if all your
production
-- aliases are in one catalog and there's a catalog error (and they do
still
-- happen), this could result in ALL of your production applications
being
-- down. One might argue increasing the # of catalogs increases
R.S. r.skoru...@bremultibank.com.pl wrote in message
news:4b7c5d62.2040...@bremultibank.com.pl...
W dniu 2010-02-17 21:26, gsg pisze:
Can having all production application aliases defined in a single UCAT cause
performance problems? If so, does anyone have any stories to tell regarding
Good practice would be to verify that the IO, and that the time spent doing
it, to the catalog is actually low, rather than thinking that it is low
because someone a few thousand km away told you it is :-)
I did say do some analysis first, before you start doing the work.
The last time I did a
3. It rather does not depend on number of aliases. BTW: The number is
limited (by the filed in MCAT), but the limit is quite big (several
hundreds AFAIR).
-- Several thousands in fact.
-- The sum of the lengths of all aliases cannot exceed 32300.
Haven't seen where anyone's mentioned that
On Thu, 18 Feb 2010 09:20:00 -0600, Darth Keller
darth.kel...@assurant.com wrote:
3. It rather does not depend on number of aliases. BTW: The number is
limited (by the filed in MCAT), but the limit is quite big (several
hundreds AFAIR).
-- Several thousands in fact.
-- The sum of the
John -
Thanks for the update on the 4GB limit for catalogs. I had not seen this
yet it's definitely good to hear that it's finally going to be resolved.
As for your other points, it appears to me that we are in complete
agreement.
-- Haven't seen where anyone's mentioned that catalogs are
W dniu 2010-02-18 16:20, Darth Keller pisze:
3. It rather does not depend on number of aliases. BTW: The number is
limited (by the filed in MCAT), but the limit is quite big (several
hundreds AFAIR).
-- Several thousands in fact.
-- The sum of the lengths of all aliases cannot exceed 32300.
Radoslaw,
I agree with you totally on this.
While I have been making the point that you should check that a single UCAT
is not a bottleneck, I believe that spreading applications across many UCAT
works against high availability. The more moving parts you have, the greater
the number of things
2. It depends on datasets activity. In fact catalog is usually used
at file open and close.
I may well display my ignorace, anyway: It is my understanding that
the catalog is only accessed at allocation time to find the volume
that data set resides on. VSAM data sets being an exeption
John Laubenheimer jlaubenhei...@doitt.nyc.gov wrote in message
news:listserv%201002181110336825.0...@bama.ua.edu...
On Thu, 18 Feb 2010 09:20:00 -0600, Darth Keller
darth.kel...@assurant.com wrote:
3. It rather does not depend on number of aliases. BTW: The number
is
limited (by the
Can having all production application aliases defined in a single UCAT cause
performance problems?
If so, does anyone have any stories to tell regarding this.
1. Define all.
2. It depends on the answer to 1.
3. With VLF, modern DASD, cache, FICON, most likely not.
4. Very general question --
When I say all, I mean all. There are probably 50 plus applications, but not
sure how many are running at the same time. We are CPU constraint as it is.
I don't know how to go about measuring this to determine if it is a problem or
not. Just trying to see if it is a possibility before
snip
I don't know how to go about measuring this to determine if it is a
problem
/snip
A good place to start is the 'f catalog,.' commands. they will tell
you lots of good things about how busy your catalogues are and their
performance.
Jack Kelly
202-502-2390 (Office)
W dniu 2010-02-17 21:26, gsg pisze:
Can having all production application aliases defined in a single UCAT cause
performance problems? If so, does anyone have any stories to tell regarding
this.
It depends - did you expect any other answer for such general question?
1. It depends on number
Would that be the F CATALOG,REPORT... commands?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at
Gsg,
Looking at Catalog and VLF statistics will tell you how well your catalog is
caching, but it will not tell you about the performance of your catalog IO.
Caching is IO avoidance, while the catalog uncached catalog activity is what
may be encountering problems.
I'd start by looking at your
When I say all, I mean all.
I was being facetious.
What I meant was what I said in my fourth point - how many.
I would recommend is that you do some sort of degradation analysis before you
do (what might be) wasted work.
-
Too busy driving to stop for gas!
...@bama.ua.edu] On
Behalf Of gsg
Sent: Wednesday, February 17, 2010 2:05 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Catalog question
When I say all, I mean all. There are probably 50 plus applications,
but not sure how many are running at the same time. We are CPU
constraint as it is.
I don't know how
If you have a sysplex, significant performance would be gained by implemention
Enhanced Catalog Sharing.
As long as ECS is working!
I've had too many bad experiences.
The I/O to the catalogue is so small, vs the files, that it's not worthwhile!
-
Too busy driving to stop for gas!
Ted,
I'm seeing examples of catalogs being in the top 1% of datasets for
read-only disconnect time. While catalog IO may represent a small percentage
of the IO for a file, the aggregate catalog IO may represent a single point
of contention and delay for the end to end application.
Also of note
Subject: Re: CATALOG QUESTION - CORRECT AN ALIAS PROBLEM
Ernie,
Good Morning Gentle Readers,
I am working on a problem regarding a TSO alias which was not
created but for some unexplicable reason I find about 15 dsns have
been cataloged in the MCAT. My question is how can I fix this problem
The best way to resolve this issue is to do the following:
1) Make sure the type of data set (VSAM vs. NON VSAM). If you have VSAM
cataloged in the MCAT you will need to work a little harder.
2) Uncatalog all of the NON Vsam data sets in the Master Cat
3) Build the Alias for the HLQ
4)
Ernie,
Good Morning Gentle Readers,
I am working on a problem regarding a TSO alias which was not
created but for some unexplicable reason I find about 15 dsns have
been cataloged in the MCAT. My question is how can I fix this
problem - have the dsns created in the proper UCAT. I
You would need to define the alias after moving the entries out of the
master catalog. You will probably get an IDC3009I 8-8 duplicate entry
(on the alias define) if you already have data sets residing in the
master catalog that begin with the alias.
Blair Svihra
Dino-Software Corp.
*
From: esmie moo [EMAIL PROTECTED]
My plan is to define the alias in the proper UCAT and then execute the
following jcl.
//STEP1EXEC PGM=IDCAMS,REGION=2048K,TIME=1440
//SYSPRINT DD SYSOUT=*
//SYSINDD *
REPRO -
This is what I use when cleaning up Catalogs. This job will move the
entries to the correct catalog without having to do any extra work. After
you have them moved to the correct catalog define your alias and you will
see the data sets. With this if you are just moving a few data sets it
has
I have to reorg some USER CATS because they contain the IMBED parm.
You shouldn't have to for z/OS 1.8, nor should you put it on your critical path
for implemementation.
Yes, support for IMBED is going away, but existing datasets don't fail, under
any release of z/OS, yet (unless I've missed an
On Wed, 2007-12-05 at 06:45 -0800, willie bunter wrote:
We will be implementing Z/OS 1.8 soon. I have to reorg some USER CATS
Oh, and lest I forget: you may want to disable autotuning, which has had
problems in z/OS 1.8. (Has IBM fixed this yet? I haven't been paying
attention.)
--
David
On Wed, 2007-12-05 at 06:45 -0800, willie bunter wrote:
My question is should I need to code the CISIZE parm (CISIZE 28672
which is being used in the current USER CAT) or is the system default
of 4096 sufficient?
At the Tampa SHARE, Eileen McClintock gave a Tuning Techniques for
Catalogs
Thanks John.
McKown, John [EMAIL PROTECTED] wrote: -Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of willie bunter
Sent: Wednesday, December 05, 2007 10:23 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: CATALOG QUESTION - CISIZE
Thanks
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of willie bunter
Sent: Wednesday, December 05, 2007 10:23 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: CATALOG QUESTION - CISIZE
Thanks to all who responded. Last question, I compared
Thanks to all who responded. Last question, I compared the PRODUCTION USER CAT
against my TEST USER CAT and I noticed in the LISTCAT of the PRODUCTION verison
it had the TEMP-EXP but it did not show in the LISTCAT of my TEST USER CAT.
Should there be reason for concern?
David Andrews [EMAIL
---snip---
Thanks to all who responded. Last question, I compared the PRODUCTION USER CAT against my TEST USER CAT and I noticed in the LISTCAT of the PRODUCTION verison it had the TEMP-EXP but it did not show in the LISTCAT of my TEST USER CAT. Should there
I looked at the manual and it seems like it says I can
do a repro nomergecat. Change the master catalog option
in iplparm, ipl and go.
Before you proceed with this:
-Run a complete set of DIAGNOSEs (catalogue all VVDSes)
and cleanup/ address any discrepancies.
-Make sure all volumes that have a
Mark Jacobs wrote:
Thanks for the pointer. I looked at the manual and it seems like it says
I can do a repro nomergecat. Change the master catalog option in
iplparm, ipl and go.
We can manage any updates in the master catalog(s) until all systems are
reipled.
Do you read it the same way I do?
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Jacobs
Sent: Thursday, April 19, 2007 2:13 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Catalog Question
Is the repro mergecat process disruptive to the source
catalog? Does the
On Thu, 19 Apr 2007 15:12:46 -0400, Mark Jacobs
[EMAIL PROTECTED] wrote:
Is the repro mergecat process disruptive to the source catalog? Does the
answer change if the source catalog is the system master catalog/
Extremely! It moves catalog entries and also switches VVDS affiliations. The
On Thu, 19 Apr 2007 15:12:46 -0400, Mark Jacobs
[EMAIL PROTECTED] wrote:
Is the repro mergecat process disruptive to the source catalog? Does the
answer change if the source catalog is the system master catalog/
Yes it is. Mergecat moves the entries from the source catalog to the target.
If
On Thu, 19 Apr 2007 15:12:46 -0400, Mark Jacobs wrote:
Our master catalog was defined with the imbed/replication options and we are
looking at the best way to migrate to a new catalog without the attributes.
RTFM Managing Catalogs. There is a section on changing the size of a catalog
that
Mark,
I am assuming that all systems in the plex are using the same mastercat.
Check out IBM Redbook - ICF Catalog Backup and Recovery - Look at Case
Senario #7. This explains two ways to do it.
http://www.redbooks.ibm.com/redpapers/pdfs/redp4212.pdf
Doing this over a period of time may not be
Mark Jacobs wrote:
Is the repro mergecat process disruptive to the source catalog? Does the
answer change if the source catalog is the system master catalog/
Our master catalog was defined with the imbed/replication options and we are
looking at the best way to migrate to a new catalog
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Habres, Richard (GTI)
Sent: Thursday, April 19, 2007 3:55 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Catalog Question
Mark,
I am assuming that all systems in the plex are using the same mastercat.
Check
I actually like building a new catalogue for each release. The only
thing in my mastcat is system required VSAM, IBM supplied datasets, OEM
datasets which are required in mastcat, and usercats/aliases for
everything else. When I build the new cat, I use a homegrown COBOL
program that reads a
And in our case, (just getting ready to install 1.7 into production)
we went from mod3 to mod 9 volumes for our opsystem packs.
I don't see how you can easily get away with not building a new master
catalog.
The way I did it:
SYSR2 = SYSR1
SYSR3 = SYSR1
(via IEASYMxx setup for a new mod9
On Tue, 2 Jan 2007 14:58:02 -0500, Jakubek, Jan [EMAIL PROTECTED] wrote:
And in our case, (just getting ready to install 1.7 into production)
we went from mod3 to mod 9 volumes for our opsystem packs.
I don't see how you can easily get away with not building a new master
catalog.
The way I did
I've found that the easiest and safest way is to stick to the alias', just
like the servpac creates.
Jack Kelly
LA Systems @ US Courts
x 202-502-2390
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email
On Fri, 29 Dec 2006 07:50:10 -0600, Daniel McLaughlin wrote:
We're starting to test 1.7, have 1.4 in production and on our sandbox. I
want to be able to use some HLQs that are in the 1.4 mastercat so I can
get to my OEM stuff on 1.7. I'm not ready for the mergecat step just yet,
at least I don't
First, I don't usually put OEM stuff in the master catalog unless it
absolutely positively has to be there. OEM stuff is better of in a
usercat. Doing so makes it easier to get to those products from other
systems with other mastercats.
Second, you can avoid this issue in the future by
I have to agree with Don. If something needs to be in the linklist or
LPA list, I try to find another way. For instance, in the LINKLIST, I'll
refer to the dataset with a vol-ser reference. I don't recall ever
having something that needed to be in the LPALIST, so I'm unsure how to
handle that
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman
Sent: Friday, December 29, 2006 10:15 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Catalog Question
I have to agree with Don. If something needs to be in the linklist
---snip
In the LPALST, the syntax is:
dsn(volser)
unsnip
Thanks, John
Rick
--
For IBM-MAIN subscribe / signoff / archive access
AM
Subject: Re: Catalog Question
snip
Second, you can avoid this issue in the future by abandoning the process
of building a new master catalog for each new release of the operating
system.
snip
--
For IBM-MAIN subscribe
Subject: Re: Catalog Question
snip
Second, you can avoid this issue in the future by abandoning the process
of building a new master catalog for each new release of the operating
system.
snip
***
Bear Stearns is not responsible
58 matches
Mail list logo
