I'm writing a general purpose QSAM I/O library to be called from a
HLL, where the JCL / dynamic allocation / dataset label will supply
nearly all of the parameters (RECFM/BLKSIZE/LRECL, etc). I would
like to make it perform well without requiring much in the way of
parameter tuning by the user
:
Kirk Wolf k...@dovetail.com
To:
IBM-MAIN@bama.ua.edu
Date:
12/05/2009 16:47
Subject:
MULTACC and MULTSDN rule of thumb
Sent by:
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
I'm writing a general purpose QSAM I/O library to be called from a
HLL, where the JCL / dynamic allocation / dataset
Thanks. The book seems to also suggest MULTACC=3,MULTSDN=6 ( the
same as my SWAG ).
Of course, any QSAM considerations aren't mentioned in the old red
book, since MULTACC/MULTSDN for QSAM is new. If I understand it, the
same considerations should apply as for BSAM, right?
Kirk Wolf
Just that I understand correctly the following
If I define the vtoc (below) as
VTOC(0,1,29) -
INDEX(2,0,45)
The VTOC starts at cylinder 0 for 29 tracks
The INDEX starts at cylinder 2 for 45 tracks.
If for some reason the INDEX was set to 5,0,45. Would we have a
John Dawes wrote:
Just that I understand correctly the following
If I define the vtoc (below) as
VTOC(0,1,29) -
INDEX(2,0,45)
The VTOC starts at cylinder 0 for 29 tracks
The INDEX starts at cylinder 2 for 45 tracks.
If for some reason the INDEX was set to 5,0,45.
If I define the vtoc (below) as
VTOC(0,1,29) -
INDEX(2,0,45)
The VTOC starts at cylinder 0 for 29 tracks
The INDEX starts at cylinder 2 for 45 tracks.
If for some reason the INDEX was set to 5,0,45. Would we have a problem with response time? Is there a set rule that
John,
I now place the vtoc, vtoc index and vvds at the beginning of the logical
volume. I size the vtoc and vvds
based on the expected number of datasets that will be allocated to the
volume. The size of the index is
based on the size of the vtoc. The only reason that I place all together at
the
In [EMAIL PROTECTED], on
09/20/2006
at 12:05 AM, John Dawes [EMAIL PROTECTED] said:
The VTOC starts at cylinder 0 for 29 tracks
The INDEX starts at cylinder 2 for 45 tracks.
If for some reason the INDEX was set to 5,0,45. Would we have a
problem with response time?
You might have
-- snip --
If I define the vtoc (below) as
VTOC(0,1,29) -
INDEX(2,0,45)
The VTOC starts at cylinder 0 for 29 tracks
The INDEX starts at cylinder 2 for 45 tracks.
If for some reason the INDEX was set to 5,0,45. Would we have a
problem with response time? Is there a set rule
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
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 and last
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
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
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 now this
recommendation
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
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 AFQ (no
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
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
.
-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
21 matches
Mail list logo
