Hi,
 
> Steve Fatula ([log in to unmask]) wrote:
> : Looking in SYSGEN, pool size, is there any issues with increasing the pool
> : size from say 1 (which is what it is now) to say 100? Seems like this
> : option might speed up logons??? Any real down side assuming I have lots
> : of memory???
>
> I'll let Stan answer this one, because he gets such pleasure out of it.  :^)
>
> [Just in case he doesn't, the downside is a waste of system resources for
> processes that never -- and I mean never -- get used.  Leave the pool size
> as you have it.]
 
By all means, go swimming!  (Sorry, it's 82 degrees and rising in my office
this morning, the A/C is down...or, how do you say?, "broken"?)
 
By "pool" I assume you mean the Job or Session "POOL SIZE" (there are two
different pools!).  Here's the way you see the current values:
(lots of stuff deleted)
 
 :sysgen
 sysgen> mi
   misc> sh
 
      JOB command           parameter        MAX          MIN         CURRENT
      -----------------    -----------    ----------   ----------   ----------
      POOL SIZE            pool                  200            1            1
 
      SESSION command       parameter        MAX          MIN         CURRENT
      -----------------    -----------    ----------   ----------   ----------
      POOL SIZE            pool                  200            1            1
 
The "CURRENT" value is the number of spare job/session main processes that
JOB or SESSION should keep around.
 
Normally, when a user attempts to logon as a session, the process
running SESSION.PUB.SYS (there'll only be one, and we'll call it "SESSION")
says "oh, I need to have a JSMAIN process to assign to your logon request
(that's a process running the program JSMAIN.PUB.SYS ... every job and every
session has one).  If SESSION had to create (via CREATEPROCESS) a JSMAIN
at the point you walked up and hit <cr> on a terminal, you'd see a small
time gap before you could start to logon.  So, the Job/Session designers
said "gee, it would be neat to have spare JSMAINs lying around, already
created and ready to be assigned to the next few logon attempts"...and thus
was born the "POOL SIZE" option.
 
If the pool size is 0, there should be no
spare JSMAINs, and each logon attempt will cause the creation of a new one.
When the job or session terminates, the JSMAIN will terminate.
 
If the pool size is 1, then there will usually be one spare JSMAIN
(if it's the JOB POOL we're talking about then the JSMAIN belongs to JOB,
if it's the SESSION POOL we're talking about, then the JSMAIN belongs
to SESSION.)  When a logon request comes in to SESSION,
it will say "oh, I have a spare JSMAIN...I'll assign it to this request".
But, we have no spare JSMAINs any more.  SESSION will eventually get around
creating another JSMAIN...but what if another logon request comes in
*now*, while there is no spare JSMAIN?  Simple...we create a new one.  If
the POOL had been 2, then we would have had one more in the pool, and thereby
put off the "at <CR> time" creation of a JSMAIN to the next time (if necessary).
 
Now, here's the important part of the POOL stuff:
   JOB (and SESSION) is not smart enough to say...hey, I have a JOB LIMIT
   (or SESSION LIMIT) of 10, and there are already 10 jobs (or sessions)
   running...therefore I don't need any spare JSMAINs.  Instead, if you hav
   a pool of 10, you'll have 10 jobs (or sessions) *AND* 10 spare, useless,
   JSMAINs sitting around!
 
I've seen several sites where, not understanding POOL, they said "we have
 a job limit of 10 and a session limit of 100, so let's set the JOB POOL
SIZE to 10 and the SESSION POOL SIZE to 100".  When they had 10 jobs and
100 sessions logged on, there were a total of 220 JSMAIN processes!  (or,
110 wasted ones!).
 
In short, I'd never set the POOL SIZE to anything above 2, and usually
would leave it at 1.
 
--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html