edgould1...@comcast.net
To: IBM-MAIN@bama.ua.edu
Sent: Saturday, May 26, 2012 9:48:46 PM
Subject: Re: REPRO MERGECAT performance
The third vendor (NOT DINO or the other) sorry I wasn't clear on that.
Using undocumented fields in the catalog is just plain inexcusable
(IMO). Reserved fields
(3rd) vendor?
Thanks,
Linda
- Original Message -
From: Ed Gould edgould1...@comcast.net
To: IBM-MAIN@bama.ua.edu
Sent: Friday, May 25, 2012 11:17:37 AM
Subject: Re: REPRO MERGECAT performance
Dave:
We took the other one and in addition there were side bennies. We
also got
,
Linda
- Original Message -
From: Ed Gould edgould1...@comcast.net
To: IBM-MAIN@bama.ua.edu
Sent: Friday, May 25, 2012 11:17:37 AM
Subject: Re: REPRO MERGECAT performance
Dave:
We took the other one and in addition there were side bennies. We
also got burned by an OEM that depended
Looking back at some emails from around that time. I *think* the
issue with repro mergecat is that it access VVD's all over the place.
I did not take time to track it down but the best explanation I got
is that it must update all the VVDS's .
Ed
On May 26, 2012, at 4:26 PM, Linda Mooney
We've just done a couple of REPRO MERGECATs that were fairly large, and took
some time, so I was wondering:
Can MERGECAT performance be improved by altering the buffer space values for
either the input or output catalog, or both?
Can MERGECAT performance be improved by altering the buffer space values for
either the input or output catalog, or both?
If you have a lot of VSAM, probably not. As I recall, doing a large repro
mergecat with a lot of VSAM was very slow, but it was mostly due to the need to
go change every
Tim,
I would love to hear about any as well.
I have done a few and the length of time (even at 0200 ) was poor. I
had to ask for 6 hours and was put off for quite some time. I ended
up leaving and really never cared what happened.
Ed
On May 25, 2012, at 8:14 AM, Tim Hare wrote:
We've
a lot of VSAM, probably not. As I recall, doing a large
repro mergecat with a lot of VSAM was very slow, but it was mostly
due to the need to go change every vvds entry.
In other words, I don't think you'll get a lot of bang for your buck.
Mary Anne
be improved by altering the buffer space
values for either the input or output catalog, or both?
If you have a lot of VSAM, probably not. As I recall, doing a large
repro mergecat with a lot of VSAM was very slow, but it was mostly
due to the need to go change every vvds entry.
In other words
be improved by altering the buffer space
values for either the input or output catalog, or both?
If you have a lot of VSAM, probably not. As I recall, doing a large
repro mergecat with a lot of VSAM was very slow, but it was mostly
due to the need to go change every vvds entry.
In other words, I don't
I'm running a REPRO MERGECAT at z/OS V1R8, getting IDC3332I **
INSUFFICIENT MAIN STORAGE trying to merge 360,000 entries into a new
catalog. I'm running 0M (also tried 250M and 500M) with no exits limiting
storage. I've got 12M private below the line. IBM is giving me the WAD,
telling me
snip
Let me know if you've had problems like this in IDCAMS, so I can flesh
out the
requirement. War stories, comments, etc. also appreciated.
/snip
Tom,
When we went for z/OS 1.6 to z/OS 1.8 we had a similar problem with the
LISTCAT function of IDCAMS. We had quite a few jobs that had a
I've seen this also. I just re-submitted the job with no changes.
Eventually the mergecat finished with the end results what I wanted.
This appears to be a case of a getmain not being followed by a freemain. It
takes a fairly large number of entries to move to pop this problem up.
On Fri, 27
problem.
Chris Mason
- Original Message -
From: Thomas Conley [EMAIL PROTECTED]
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@BAMA.UA.EDU
Sent: Friday, July 27, 2007 8:48 PM
Subject: IDC3332I ** INSUFFICIENT MAIN STORAGE in IDCAMS REPRO MERGECAT
I'm running a REPRO MERGECAT at z/OS V1R8
On Jul 27, 2007, at 1:48 PM, Thomas Conley wrote:
SNIP--
Let me know if you've had problems like this in IDCAMS, so I can
flesh out the
requirement. War stories, comments, etc. also appreciated.
Regards,
Tom Conley
Tom,
I have done 2 or 3 repromergecats in
of doing a Repro mergecat with volumeentries specified, to
merge from the VGENERAL into a newly defined/allocated specific volcat Vx.
Will this work ...
Thanks for any answers or comments.
Om Prakash
What is a VOLCAT? Your name for a user catalog? I would think yuo should
stop trying to use catalogs
] On Behalf
Of Kenneth E Tomiak
Sent: 18 July 2007 10:25
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Repro Mergecat of Volcats
On Mon, 16 Jul 2007 18:22:02 -0500, Om Prakash Thangavelu
[EMAIL PROTECTED] wrote:
Hi All,
We would like to split our SYS1.VOLCAT.VGENERAL into specific volcats
(SYS1
Hi All,
We would like to split our SYS1.VOLCAT.VGENERAL into specific volcats
(SYS1.VOLCAT.Vx). Anyone out there has done it in the past. Please share
your comments or some sample jcl.
We are thinking of doing a Repro mergecat with volumeentries specified, to
merge from the VGENERAL
Good Day To all,
I will be performing a catalog clean up. I will be doing a REPRO MERGECAT.
My question is will that process delete the alias or do I need to delete the
alias before I redefine it?
Below is my jcl:
//MERGECAT EXEC PGM=IDCAMS,REGION=4M,TIME=1440,COND=(0,NE
To: IBM-MAIN@BAMA.UA.EDU
Subject: REPRO MERGECAT
Good Day To all,
I will be performing a catalog clean up. I will be doing a REPRO
MERGECAT. My question is will that process delete the alias or do I
need to delete the alias before I redefine it?
Below is my jcl:
//MERGECAT EXEC PGM
20 matches
Mail list logo
