Re: Check your ancient performance settings

Hello Vern,

Am 09.10.2019 um 15:46 schrieb Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>:

I should have said QBASE - I just was not at a system, so I was trying to remember these things.

NP.

If you specify QBASE as your controlling subsystem, almost everything runs in pool 2. If you specify QCTL, several workloads run in their own fixed pool or in shared pools.

I partly agree. QCTL enables a lot of previously inactive subsystems. But as most jobs *might* run in separate subsystems, the shared pool most of them use is *BASE. Exceptions are *INTERACT and *SPOOL.

But the recommendation to use QCTL instead of QBASE suggests to me that it is worth splitting some things into their own pools.
I mentioned a couple examples, others on the list, such as Jim Oberholtzer, have given help on moving various workloads into their own pool - web serving is one example, where you don't want users to wait for on-system tasks to go through their work before the resources are available to the web or ODBC or other remote request.

As far as I understand, shared pools are about memory or main storage, and paging activity levels. Subsystems are about grouping jobs with appropriate time slices and/or priorities, and enable routing of "incoming work" to these subsystems. Right?

Please don't get me wrong, I don't want to offend in any way. I just have a (maybe sometimes nasty) habit to ask back when I feel that an answer maybe has been given because of because-we've-done-it-that-way-ever-since. :-)

Yes, things are faster, there is more space that runs better (SSDs), so I still think if that is all good, you can do even better where needed by separating workloads into separate pools.

You are right. To do so, I'd need a solid understanding of what's really going on behind the scenes.

:wq! PoC

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