× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



There are 2 aspects, at least, to your question, seems to me. One is the definition of a shared pool, which, as someone else stated, is a pool in which more than one subsystem can run its jobs. E.g., a shared pool can be specified on the CHGPOOL command for more than one subsystem. The other, perhaps simplistic answer is, any pool with a name that starts with an asterisk. *BASE has always been around and has been a shared pool all along. More recently (eary '90s?), *SPOOL and *INTERACT were added. Private pools, OTOH, are identified by the name of their subsystem in the WRKSYSSTS display - you need to rotate through the views with F11 to see these names.

In WRKSYSSTS, only shared pools can have their paging options set to *CALC. This can result in better performance, as it can reduce physical IOs and DASD contention.

There are a couple APIs related to this. Change Pool Attributes (QUSCHGPA) API is used to change attributes for both private and shared pools - it knows what to do for each type. It has a paging option parameter, but I don't remember whether it is valid for private pools.

Change Pool Tuning Information (QWCCHGTN) API, OTOH, _CAN_ be used to change the paging option even for private pools. It opens the door to trouble-filled micro-management, I think, but it IS there, nonetheless. The documentation is helpful for an understanding of expert cache. If you want to know even more, there is an option of the MATRMD API that returns all this pool tuning information. The docs for that come from a different angle and can be a little confusing at first - it IS the high-level interface to the MI instruction, after all.

I think, and the manual suggests, that all shared pools should be set to *CALC. The *MACHINE pool is an exception, IIRC - it cannot be set to *CALC. But we can't use it as a subsystem pool anyway.

Hope this is only a little confusing - enjoy the holiday!
Vern
46f2d7.jpg

At 07:36 AM 11/24/2004, you wrote:
How does one make a determination on what is a "shared pool" and should be
set to *CALC?

              Defined    Max   Allocated   Pool  -Paging Option--
Pool         Size (M)  Active  Size (M)     ID   Defined  Current
*MACHINE      1407.56   +++++     1407.56    1   *FIXED   *FIXED
*BASE         6670.02    1337     6670.02    2   *CALC    *CALC
*INTERACT     4871.39     458     4871.39    3   *FIXED   *FIXED
*SPOOL         269.19      46      269.19    5   *FIXED   *FIXED
*SHRPOOL1     5083.87      80     5083.87    4   *CALC    *CALC

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





Vernon Hamberg <vhamberg@xxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
11/24/2004 01:50 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> cc

Subject
Re: Why separate pools?






I stronlgy recommend that you set all shared pools to *CALC. This is expert cache, and it affects the I/O block size for transferring data from DASD. *FIXED forces this size to 4K (and maybe 16K for SQL indexes, or something

like that), but it is possible to have a block size as large as 128K.
Expert cache uses a sliding window (about 4 minutes, I think) for
measuring
disk I/O in regard to data files. The database engine reports its I/Os to
expert cache, which changes the block size, depending on whether access to

data is completely sequential (large block size, since everything is
contiguous on disk), to completely random access, where records are
accessed by key and are not located close together on disk.

There can be tremendous gains in I/O - the actual time to bring in a block

of any size is essentially the same, so the more you can transfer in a
request the better.

You can see some of these numbers in WRKDSKSTS. There are 3 columns that
report request size - the one in the middle is average size for both reads

and writes. To the right are separate columns for each operation.

HTH
Vern

At 12:43 PM 11/23/2004, you wrote:
>Regarding wrkshrpool, F11 paging options, *FIXED vs. *CALC.
>
>Two questions:
>
>1) If qpfradj is 2 or 3 and all the wrkshrpool paging options are *FIXED,
>doesn't the performance adjuster still continue to move ram between the
>pools with the page size remaining the same (*FIXED) across all pools (at
>4k ? - or whatever size the pages are)?
>
>2) If *FIXED is changed to *CALC,  isn't this what the manuals refer to
as
>'expert cache'? And doesn't that mean the expert cache only affects the
>calculation of the page size within that pool, (which indirectly affects
>the amount of ram moved in/out of the pool)?
>
>
>Regards, Jerry
>
>Gerald Kern
>IBM Certified AS/400 RPG IV Developer & RPG IV Programmer
>MIS Project Leader, Lotus Notes/Domino Administrator
>The Toledo Clinic, Inc.
>4235 Secor Road
>Toledo, OH 43623-4299
>Phone 419-479-5535
>gkern@xxxxxxxxxxxxxxxx

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


-- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.