|
Cyndi Bradberry wrote:
As you can see below, most of our subsystems are in pool 2. Byteme (programmers sybsystem) and QINTER are shown in 2 & 4. QUSRWRK is in pool 2. We have been busy beavers and have nearly 80 jobs running in QUSRWRK (socket servers that are in TIMW mostly). Work with Subsystems System: BOISE Type options, press Enter. 4=End subsystem 5=Display subsystem description 8=Work with subsystem jobs Total -----------Subsystem Pools------------ Opt Subsystem Storage (M) 1 2 3 4 5 6 7 8 9 10 BYTEME .00 2 4 FAXCOM .00 2 LSAMS 22.00 5 QBATCH .00 2 QCMN .00 2 QCTL .00 2 QINTER .00 2 4 QPGMR .00 2 2 QSERVER .00 2 QSPL .00 2 3 QSYSWRK .00 2 QUSRWRK .00 2 TESTSBS .00 2 4
Cyndi:Just a comment to start... From this, we can't tell much except that BYTEME, QINTER and TESTSBS have subsystem pool entries for the *INTERACT shared pool along with pool entries for *BASE (plus similar info for other subsystems). Those subsystem pool entries make those pools available for work in those subsystems.
However, there is no way to tell from this if any one of those three are actually _using_ *INTERACT rather than *BASE.
From your system status display, there is activity in *INTERACT; but we can't tell what that activity came from.
The usage of pools is determined by reviewing the various routing entries and pre-start job entries for the subsystems.
Beyond that, I think Rob suggested looking at your disk status, which is a very good first step when performance drops are noticed with no expected reason. And I think Trevor gave about as good of an 'executive overview' of performance tuning basics as is possible.
But, be aware that starting performance adjustments might not do much good if you don't first configure your system to give it something to adjust. For example, it looks as if you have most functions lumped into *BASE. Since they're not broken out into separate shared pools, there's no way for performance adjuster to move memory to the shared pools that request more memory.
In short, you don't have much in the way of pools beyond the default from IBM. IMO, the default is simply good enough to get by okay. (And I don't see how IBM could get it much better than they do without knowing far more about each environment.)
Tom Liotta
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
