|
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 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.