RE: Why separate pools?

As you've been hearing, Rob, separate pools make sense primarily in the
case of separate work loads.  Typically, a given machine might have two
or three "user" pools (plus there's always the system pool, where the OS
keeps its most important bits): one for interactive, one for batch, and
maybe a tiny one for spooling.

The interesting thing about the iSeries (and it's been this way since
the CPF days) is that if you have 50 users signed on to order entry in
the same pool, only ONE copy of the OE program is loaded.  Each user
gets their own space for data (which these days is the F specs and D
specs plus miscellaneous bits), but the program itself is only loaded
once.

This does NOT work across memory pools.  If you have two users in two
different pools running order entry, you have two copies of the program
AND the data.  So running like jobs together in the same pool is really
good advice.

A last bit on this: Java does NOT work and play well with typical OS/400
work.  For whatever reason, if the JVM is subject to paging, performance
suffers horribly.  Thus, if your JVM and your interactive users share
the same pool, nobody wins.  It is always best to hack off a chunk of
memory into a pool and give it directly to any Java jobs (especially
WebSphere).

Joe


> From: rob@xxxxxxxxx
> 
> Thank you.  That made sense.