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