Patrik:

Getting to know how the memory pools (each has a very different role) interact may be slightly daunting at first, however once you understand it, it's really quite easy. It's a bit unfortunate that the names are so similar but once you process it, it will be clear. (You are not alone, almost every PowerUp conference I go to I wind up spending quite some time helping folks understand this concept)

There are two absolutely required shared pools: *MACHINE and *BASE.
*MACHINE is where IBM I, and 90% of it's parts run.
*BASE is the default shared pool.
IBM provides a total of 64 shared pools: *MACHINE, *BASE, *INTERACT, *SPOOL, and 60 shared pools.

If the system were in restricted state, then all the memory not assigned to *MACHINE will be in *BASE.

As each of the shared pools is used, the system will allocate memory from *BASE to that shared pool, in this case *SHRPOOL1

Using *BASE as the first subsystem memory pool is a best practice since that is where the subsystem job gets it's memory and activity level. That way the subsystem can act with the job queues assigned to it, start/stop jobs without having to fight with the application programs running in that subsystem.

If the autotune function is turned on (system value: QPFRADJ) then the system monitors faulting/paging and adjusts the system as necessary. For most workloads this works well. In more advanced systems manual is better.

As to my memory, sadly it's not as good as POWER System is, but even after nearly 40 years of doing this some things have stuck, thanks.

--
Jim Oberholtzer
Agile Technology Architects

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Patrik Schindler
Sent: Monday, December 30, 2019 10:06 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Reducing ODBC connection impact

Hello Jim,

Am 29.12.2019 um 17:53 schrieb Jim Oberholtzer <midrangel@xxxxxxxxxxxxxxxxx>:

What you are referring to is the subsystem pool (1 in your example)
and the system pool (5 in this case) which is assigned by the system
when the shared pool (*SHRPOOL1) is first used by the system.

This confusing ID schema is not very helpful in getting a grip. :-)

Best practice says (particularly at the early version release you are
using) to always have *BASE as subsystem pool 1, and the memory you
want the jobs to use as subsystem 2 (or higher but that’s rare).

You’ve discovered the CHGSBSD command. It should look like:

CHGSBSD QSERVER POOLS((1 *BASE ) (2 *SHRPOOL1))

Thanks. I'm not sure how the OS handles such configuration. Memory is taken from *BASE. When is memory in *SHRPOOL1 utilized?

Then you must change the routing to force the system to use the subsystem pool 2.

Ah, okay. So the *BASE entry is just some kind of safekeeper?

Of course, questions answered raise new questions. :-) Would it maybe better to utilize a SBS-private pool? AFAIK, these can't be changed as shared pools can be by perfadjust but I don't think this is abig deal. More interesting would be how big I should size that memory pool.

Sorry if I messed up the commands, typing on my phone and going from
memory since not connected to a system at the moment.

No worries, you seem to be correct going just from memory. :-)

:wq! PoC

PGP-Key: DDD3 4ABF 6413 38DE - https://www.pocnet.net/poc-key.asc


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

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2022 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.