RE: How Memory Pools work

Adam:

My first recommendation is to go to the InfoCenter and start learning the 
basics of Work Management. A quick search should lead you to a topic like <How 
work gets processed> and a lot about memory pools is referenced there.

>From the Work Management guide, a couple items that I've noticed about *BASE:

1. "*BASE is the base storage pool that contains all unassigned main storage on 
the system; that is, all storage that is not required by the machine storage 
pool or by another pool."

2. "The storage pools that you define decrease the size of the base storage 
pool."

Somewhere in years past, I recall seeing a writeup that describes memory 
"movement" from one pool to another. I might be misremembering, but I believe 
from the above two points that whenever memory is reassigned from pool X to 
pool Y, it must be assigned to *BASE as an intermediate step.

For me, the implication has been that I don't want _any_ jobs running in *BASE 
if I can help it. That includes jobs from IBM-supplied prestart job entries, 
autostart jobs, etc. I define at least a couple *SHRPOOLxx pools and assign 
them to subsystems such as QSYSWRK in order to have subsystem pools I can 
associate with routing entries, etc.; and I change _all_ such entries to avoid 
*BASE. If all kinds of stuff is running in *BASE, how effectively can memory be 
managed?

This allows me to have a *BASE that mostly does what Work Management says it 
should do -- act as my unused memory repository. When I need to know if my 
system has enough physical memory, the first quick check is then simply to see 
if *BASE regularly has memory to spare.

By assigning pools, one advantage can be that memory is immediately available. 
Perhaps not as much as the job will eventually need, but you can allocate 
enough to give a job somewhere to start without competing with too many other 
jobs. If memory is in use elsewhere, it takes time to reassign it. By not 
assigning pools, you lose a lot of your ability to make subsequent performance 
related decisions.

Of course, if you don't have enough physical memory in the first place, it 
might all be moot.

Tom Liotta

midrange-l-request@xxxxxxxxxxxx wrote:

>   1. How Memory Pools work (Adam Lang)
>
>Can someone explain how memory pools work?  Our system currently has 256 MB
>total and apparently our interactive is around 150-160.  We also have a
>machine, base and spool pool.
>
>We have a windows based app that is using Communication Frameworks to call a
>program on our AS/400 to rate auto insurance policies.  It is taking a long
>time to get an exit back from the as/400 program.  The vendor is saying it
>is because we have no batch pool and that it is processing in the base pool
>and trying to pull memory form qinter (interactive).  I would appreciate if
>some of you more knowledgeable folks could give a high and low over view of
>high memory pools work on the as/400.  I hate having to take a vendor's word
>for it. ;)

-- 
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertech.com


__________________________________________________________________
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455