Good morning,
we are revising central storage due to our systems not paging and,
therefore, it's possible that we have installed too central storage.
We have seen to find values or some rule of thumb but we don't find
anything.
At 1991 the recommendation was 300-500pag/sec of total paging but no
.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of DMR-Qualitas Outsourcing
Sent: Wednesday, December 21, 2005 6:19 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Rule of thumb about paging / page fault rate
Good morning,
we are revising central
Mmmm - that recommendation would have been from the days when we all had
expanded. You really wouldn't want to try and sustain that rate to round
brown spinning stuff.
It's good these days, but as Hal said, it's slow.
Zero is a good target.
As usual it's horses for courses - some envir
Most OS performance rules of thumb were developed for TSO and simple batch
workloads where each address space (region) served a single 'user' and did
no async i/o or any self directed, non os service task management.
To the extent that workloads have shifted to to multi user address spaces
that of
Hi,
In a related topic does anyone have thoughts or recent references to
settings for MCCAFCTH in PARMLIB IEAOPTxx?
I currently use MCCAFCTH=(5000,6000), on my OLTP production partitions
with 32M and very large AFQ (no paging) and still have
MCCAFCTH=(2000,2500), for my test and development parti
On Thu, 22 Dec 2005 12:14:01 -0500, Knutson, Sam <[EMAIL PROTECTED]> wrote:
>Hi,
>
>In a related topic does anyone have thoughts or recent references to
>settings for MCCAFCTH in PARMLIB IEAOPTxx?
>
>I currently use MCCAFCTH=(5000,6000), on my OLTP production partitions
>with 32M and very large AF
>Most OS performance rules of thumb were developed for TSO and simple
batch workloads where each address space (region) served a single 'user'
and did no >async i/o or any self directed, non os service task
management.
>
>To the extent that workloads have shifted to to multi user address
spaces tha
Hi folks!!
Thanks a lot for your answers. I'm learning a lot with you.
At DB2-list (http://www.idugdb2-l.org/archives/db2-l.html) I found
following discussion:
**
I read the value 100 in a Chuck Hoover's article:
'If the sum of
"Christian Blesa" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL
PROTECTED]>...
> Hi folks!!
>
> Thanks a lot for your answers. I'm learning a lot with you.
>
> At DB2-list (http://www.idugdb2-l.org/archives/db2-l.html) I found
> following discussion:
>
>
The ROTs are fine (old and current), but there is really only one
thing that matters and you may be paging, or you may not be
Are you meeting your SLAs?
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America and Farmers Insurance Group
mailto: [EMAIL PROT
On Fri, 23 Dec 2005 15:33:47 -0600, Mark Zelden <[EMAIL PROTECTED]>
wrote:
>The ROTs are fine (old and current), but there is really only one
>thing that matters and you may be paging, or you may not be
>
>Are you meeting your SLAs?
>
>Mark
Hello Mark,
of course, to meet SLAs is the first an
Chr.
Have you done some paper and pencil storage estimates
On a LPAR assume
2 gig for each of
Z/os
OMVS
Each DB2 subsystem
Each IMS subsystem
Each MQ subsystem
Each CICS subsystem
5 Batch address spaces
20 TSO users
If you have 14 gig available to an LPAR and one each of the above items
you may b
12 matches
Mail list logo
