× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Mike:

Though your *MACHINE pool might be fine, *BASE could be being used 
inefficiently and that's part of Jim's point I think. Consider the following 
from the Work Management Guide:

<quote>
Separating Batch Work from *BASE
 
Performance for batch work may improve if the jobs are moved to a separate
pool. Batch work includes traditional batch jobs and other non-interactive
functions, such as Internet server jobs, and database server jobs.
</quote>

There's more, but the key part here is the designation of the Internet and 
database server jobs as 'batch' rather than 'system' jobs. IBM's default 
routing entries have traditionally routed these jobs to *BASE even though 
tuning guidelines say that performance can improve if these are _not_ routed to 
*BASE but instead to a separate pool. (I think 'system' jobs are generally 
those that appear left-justified in the Subsystem/Job column of WRKACTJOB.)

Aside from the use of *BASE to run SCPF, QSYSARBxx, etc., I view the purpose of 
*BASE as being the place where unused memory sits, waiting to be assigned to 
other pools as needed. By having no user/batch jobs running in *BASE, the 
memory doesn't need to be cleared, paged out, or whatever extra processing 
might happen, before being used by some other process.

Further, AFAIK, memory _always_ comes out of *BASE when another pool needs it. 
If *BASE doesn't have memory to give, the memory is first taken from another 
pool, put into *BASE and then given to the requesting pool.

In any case, I routinely set aside one or two of the *SHARExx pools for the 
various "Internet server jobs, and database server jobs", etc., and assign 
those pools to the relevant subsystems. Then I change routing entries for those 
jobs to point to the new pools. This tends to keep some of the memory out of 
*BASE and reduces the chances of it needing to be paged out/in/cleared, etc., 
and helps me get a better picture of what the _real_ *BASE requirements are. 
Simplified example, if *BASE continually remains large, you have a bunch of 
spare, unused memory; if it's continually small, you are memory constrained. 
(Definitions of "large" and "small" don't necessarily mean only as a percentage 
of total memory, but must also include faulting, paging, etc. specifically in 
*BASE.)

I realize it's fairly crude as a guideline, but I've always seen definite 
performance improvements.

Tom Liotta

midrange-l-request@xxxxxxxxxxxx wrote:

>   6. RE: Model 270 At V5R2 Is Dead Toad Slow Running JDE One
>
>Machine Pool is at 204.5 MB.  Machine pool is fine.
>
>-----Original Message-----
>
><snip>
>
>That is all fine, system is set to tune itself via system value
>settings.  Pools are the same size at V5R2.
>
></snip>
>
>Another thing to be aware of.  Unless you have changed it, JDE runs all
>the QZDASOINIT jobs it needs in *BASE.  In my view a very bad thing.
> With that configuration JDE is fighting OS/400 for resources.  Everyone
>
>looses in that case.  You should consider moving these server jobs into
>a separate subsystem where you can properly tune and control them.

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


__________________________________________________________________
Try AOL and get 1045 hours FREE for 45 days!
http://free.aol.com/tryaolfree/index.adp?375380

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

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.