Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

a tuning question .....

10 views
Skip to first unread message

Chris Hoelscher

unread,
Nov 7, 2002, 3:45:54 PM11/7/02
to
I am tacklinjg some long overdue performance/tuning activities, and would
appreciate any practical experience from those who have gone before ...


1) I am adjusting size of our XA storage pools. if a months worth of stats
shows that the the HWM for an XA storage pool is (lets say) 5000K, to what
valyue would you adjust the pool 7500K, 1000K, 15000K? (in other words,
what percentage of the size to you like to see the HWM of a pool sitting
at? - 67%, 50%, 33%, etc?)

thanks

chris hoelscher

Cherlet, Gary , JTS

unread,
Nov 7, 2002, 5:19:45 PM11/7/02
to
First rule - if your system paging is acceptable than no increase to any
"pool" (buffer, storage, program) should cause your system paging to become
unacceptable.

Second rule - our "local" ROT for storage pools is that the HWM should stay
below the cushion - because as soon as you start getting into the cushion
you know that new tasks are not being started - so there is some queuing
time being added into internal response time (does anybody know if there is
a measure of queuing time while waiting to start - as contrasted to WAIT
time while a task is running?).

For what it's worth I've included our 6:00pm "snapshot" of our storage pool
and scratch utilisation - the storage pool pages are 4k pages if you want
the size in Mb. We're in the process of adding in a storage pool 1 to all
our CV's to avoid a possible system-wide SOS hanging the system - as per
John Siracco's suggestion in the tuning session at the last IUA Workshop -
you'll notice it's not in this CV yet.

Cheers - Gary

JISTATS

****************************************************************************
***
Tape CV Num Julian Date+Time
*
E1GJ3M 20 2002311 18:00
*

****************************************************************************
***
Pool Pages In Use HWM Times SOS Cushion SSUUTDS
*
HKSKRBY
*
0 1500 73 141 0 300 XXXXXXX
*
4% 9% 20%
*
128 10000 1577 6113 0 1500 XXXXXX
*
15% 61% 15%
*
129 750 270 463 0 0 XX
*
36% 61% 0%
*
255 6000 1753 4469 0 0 X
*
29% 74% 0%
*

****************************************************************************
***
Scratch-> Lo Page HI Page Alloc HWM
*
50001 59000 1895 6057
*
Percentages ------------> 21% 67%
*

****************************************************************************
***
Terminals Users HWM
*
537 159 470
*

****************************************************************************
***

Wood, Chris

unread,
Nov 7, 2002, 5:41:17 PM11/7/02
to
Gary,

Not having been in San Diego, what did John suggest go into pool 1? We have
had a pool 1 for US/UK and pool 2 for SH/SK for sometime. Pool 0 is SY/TR/DB
here.

Thanks

Chris Wood
Alberta Department of Energy
CANADA

Cheers - Gary

JISTATS

****************************************************************************
***

thanks

chris hoelscher

This communication is intended for the use of the recipient to which it is
addressed, and may contain confidential, personal and or privileged
information. Please contact us immediately if you are not the intended
recipient of this communication, and do not copy, distribute, or take action
relying on it. Any communication received in error, or subsequent reply,
should be deleted or destroyed.

Cherlet, Gary , JTS

unread,
Nov 7, 2002, 6:15:27 PM11/7/02
to
You may be OK because you do have additional "below the line" storage pools.
John's experience (and mine on the basis of every shop I've ever been at) is
that most shops don't define additional "below the line" storage pools and
so are exposed to the potential for a system-wide SOS situation that
IDMS-CV/DC won't be able to recover from - and so it ABENDs. Here's my notes
from John's session:

Always define a "below the line" storage pool
o For example: add storage pool 1 contains types ( all ) size 500 .
o Doesn't need to be big
o Will prevent SP 0 from going SOS - so will keep system up when it
would otherwise fall over

Cheers - Gary

Steve Laufer DNET

unread,
Nov 8, 2002, 8:48:09 AM11/8/02
to
Why not just increase pool 0 by 500 rather than defining an additional
"below the line" storage pool with a size of 500. I'm sure there's a good
reason, just isn't coming to me at 5:30 AM.
thanks,
Steve Laufer

Hall, Dan , CORP

unread,
Nov 8, 2002, 9:00:42 AM11/8/02
to
Steve,
The reasoning is that you may have a problem program use up all of pool 255, then overflow into pool 0, filling both pools. By having a pool 1, you give the system some storage to work with to clean up the offending task.

Laura Rochon

unread,
Nov 8, 2002, 9:13:46 AM11/8/02
to
Steve,

If the system needs to allocate overflow lock tables (for example), it
will do it in a xa storage pool. If that pool fills up, it will
allocate below the line. If you fill up pool 0, then CV tends to hang.
You can't cancel the task as you have no system space left. If you
define another "below the line pool" (for ALL), then only system storage
will go into pool 0. Therefore, if the CV fills up a XA storage pool,
it will start allocating in that other pool below the line and fill it
up. But then your system isn't completely hung, and you can actually
cancel the task, as you have system storage available (in pool 0) to
cancel it.

Laura Rochon

Petzold, Lutz

unread,
Nov 8, 2002, 9:20:21 AM11/8/02
to
But, but, but when the tiny pool 1 is exhausted, is pool 0 searched to
satisfy the storage allocation? I don't understand John's suggestion unless
he's saying that IDMSDC searches only one below the line pool after the
eligible xa pools are full, and then gives up. This makes sense to me if
pool 0 is for certain storage types only, but I thought that pool 0's
storage types are hard coded, and will satisfy any type of request.

Lutz Petzold


This e-mail, including attachments, is intended for the exclusive use of the
person or entity to which it is addressed and may contain confidential or
privileged information. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified that
any dissemination, distribution or copying of this e-mail is prohibited. If
you think that you have received this e-mail in error, please advise the
sender by reply e-mail of the error and then delete this e-mail immediately.
Thank you. Aetna

Petzold, Lutz

unread,
Nov 8, 2002, 9:28:33 AM11/8/02
to
And a lock table overflow is not system storage?

Lutz Petzold


Steve,

Laura Rochon

Steve Laufer DNET wrote:

This e-mail, including attachments, is intended for the exclusive use of the

Laura Rochon

unread,
Nov 8, 2002, 9:41:19 AM11/8/02
to
I think it fall under DB storage.

Laura

GADDY, SHIRLEY , CONTRACTOR

unread,
Nov 8, 2002, 10:12:54 AM11/8/02
to

Linda Campbell

unread,
Nov 8, 2002, 12:35:16 PM11/8/02
to
But the overflows are allocated in pool 255, which is only system storage
right?

James Ritterbusch

unread,
Nov 8, 2002, 1:43:25 PM11/8/02
to
Laura,

I'm still not clear on your suggestion, but let me play it back and see if
I have it right. Now I have these pools:

0 displays SY, ALL
128 displays SH, SK, TR, DB
129 displays US, UK
255 displays SY

Are you saying that if I now add a pool 1 below the line, and specify type
ALL, will that automagically remove the ALL type from pool 0? Since pool 0
is defined in the SYSTEM statement, it does not give me the option to
specify what type are or are not in it, right?

Now, going back to Chris' original question, what if one of our XA pools is
already over-sized? If we want to pare it back, how far can we safely go?
How much headroom above the HWM is enough?

Jim Ritterbusch

Laura Rochon <l.ro...@VIDEOTRON.CA>
To: IDM...@LISTSERV.IUASSN.COM
Sent by: IDMS Public Discussion cc:
Forum <IDM...@LISTSERV.IUASSN.COM> Subject: Re: a tuning question .....

Friday November 8, 2002 08:52 AM
Please respond to IDMS Public
Discussion Forum

Chris Hoelscher

unread,
Nov 8, 2002, 1:57:33 PM11/8/02
to
I did just that on my own private CV after adding a storage pool 1 with
types (ALL) - i now get the following:

D ALL STO POO
POOL ADDRESS SIZE CUSHION INUSE HWM TIMES PFIX CONTAINS
SOS TYPES
0 001ED000 2100K 100K 140K 156K 0 NO SY,TR,DB
130 1829D000 3600K 100K 272K 372K 0 YES ALL
1 003FA000 100K 12K 52K 76K 0 YES ALL
255 18621000 6000K 0K 244K 288K 0 NO SY
V23 ENTER NEXT TASK CODE:


from a previously opened issue with CA - i know that there is *NO* TR-type
storage ever allocated into an IDMS environment, so the only thing still
left in SP0 is DB-type storage!


chris

(14.1 SP3)

Wood, Chris

unread,
Nov 8, 2002, 2:18:37 PM11/8/02
to
Jim,

I can tell you that if you specify types for your below the line pools then
what is left goes to pool 0. You should see that from my original answer.

Pool 0 is SY/TR/DB
pool 1 for US/UK
pool 2 for SH/SK

We never tried pool 1 as ALL as we wanted to see what type of storage was
needing all the storage. We tried to make the cushion for pool 0 large
enough to at least allow it not to SOS but this has not always happened.

Chris Wood

Steve Laufer DNET

unread,
Nov 8, 2002, 2:20:28 PM11/8/02
to
Jim;
I have the same pools defined with the same storage types. The System
Generation
manual does state that if secondary pools are defined, at least one should
be
below the line. It doesn't explicitly say why, but it's implied that the
reason for
this is to separate user-program storage from system storage. At this point
I see
the benefit of having another 24 bit storage pool, however I don't see why
you would
define it for ALL types of storage, I would think it would be better to
just have it
defined for system storage. I would think that if it was defined with all,
a rogue
user-program could suck up all of pool 0 then go on and take out pool 1.

Petzold, Lutz

unread,
Nov 8, 2002, 2:42:07 PM11/8/02
to
I believe it's cast in concrete that pool 0 is the pool of last resort. So
1 would be exhausted, if eligible, before 0.

-----Original Message-----
From: Steve Laufer DNET [mailto:SLa...@DELTA.ORG]

Steve Laufer


Laura,

Jim Ritterbusch


Steve,

Laura Rochon

Steve Laufer DNET wrote:

This e-mail, including attachments, is intended for the exclusive use of the

Steve Laufer DNET

unread,
Nov 8, 2002, 2:40:52 PM11/8/02
to
Yeah, I just added a storage pool 1 - size 500k, with types (ALL),
and storage pool 1 went SOS 43 times during startup! We do have a lot
of started tasks that get initiated as part of the startup process, but
the original suggestion that reportedly came from CA, add a pool 1, size of
500, types ALL,
may not be appropriate in all cases.


-----Original Message-----
From: Chris Hoelscher [mailto:choel...@HUMANA.COM]
Sent: Friday, November 08, 2002 10:44 AM
To: IDM...@LISTSERV.IUASSN.COM
Subject: Re: a tuning question .....

Petzold, Lutz

unread,
Nov 8, 2002, 3:11:55 PM11/8/02
to
Did pool 0 usage go up?

Lutz Petzold

-----Original Message-----
From: Steve Laufer DNET [mailto:SLa...@DELTA.ORG]


chris

(14.1 SP3)

This e-mail, including attachments, is intended for the exclusive use of the

Wood, Chris

unread,
Nov 8, 2002, 3:27:36 PM11/8/02
to
And you never mentioned what pool 0 HWM was after startup. What this
exercise shows is that the started tasks used pool 1 first then pool 0 as
you had pool 1 defined as ALL.

Chris Wood

Lutz Petzold


chris

(14.1 SP3)

This communication is intended for the use of the recipient to which it is

0 new messages