Re: Why not *SHRPOOL1?

>Just curious, what is the paging setting for these pools?
=
System    Pool    Reserved    Max   Paging
 Pool   Size (M)  Size (M)  Active  Option
   1     2587.68    656.50   +++++  *FIXED
   2     2582.59     55.16     530  *FIXED
   3      168.98      <.01      80  *CALC 
   4      117.75       .00      20  *FIXED
   5     9542.97       .23     227  *FIXED


>I notice that *SHRPOOL1 already has more memory - is this the status 
before 
starting the big job?
=I am not aware of any particular 'big job' for that time period.  By the 
way, it is now:
System    Pool 
 Pool   Size (M)
   1     2587.68
   2     2582.59
   3      168.98
   4      117.75
   5     9542.97
versus the earlier:
System    Pool
  Pool   Size (M)
    1     2618.98
    2     6307.05
    3     3935.35
    4      303.44
    5     1835.15

>Also, you have to have at least 3 pools - including *BASE. And probably 
4, 
with *SPOOL.
=You're probably right, we would need 3 pools:  *MACHINE, *BASE and 
*SHRPOOL1.  You could probably modify the subsystem description for QSPL 
to use one of these three pools - *SHRPOOL1.  (Why preallocate memory that 
might be better utilized elsewhere?)

>Now it IS possible to change shared pools so they have a minimum size, 
using WRKSHRPOOL (F11). So  you could reserve a certain percentage of main 

memory, even if a subsystem becomes relatively inactive.
=That would seem like a waste of memory - tying it up when it could be 
better utilized elsewhere.  Unless you want to avoid the QPFRADJ delay 
when the load switches.  This is why we were thinking of lowering the 
number of pools.

>There's also a priority for shared pools, I assume for which gets memory 
or 
activity levels first.
=I see that priority in WRKSHRPOOL.  And the help for it discusses it's 
relationship with QPFRADJ.  Just doesn't say if your assumption has any 
bearing.  Rather vague.

>Also, with so many activity levels in *INTERACT, it may take longer to 
get 
things going.
=At what level does that come a factor?

>Now, if by experience witht the app, you have an idea how much it needs, 
do 
a CHGSBSD to adjust the pool size first.
=The problem is that with 517 users currently signed on, and 472 currently 
running batch jobs (according to DSPSYSSTS at basic level - how it 
interprets a job as batch I don't know - there are only 25 jobs in the 
QBATCH subsystem), 406 WRKJOBSCDE jobs, several totally independent 
divisions we gave up trying to manually figure out when to transfer memory 
from one shared pool to another, hence that is why we turned on QPFRADJ.
In days of old we used to have a job called NIGHT and a job called DAY 
which were scheduled to transfer memory from one pool to another. 


Rob Berendt
-- 
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety." 
Benjamin Franklin