Re: carve out QSYSWRK it's own (shared) memory pool

Additionally there are some prestart and autostart jobs in that subsystem that may need to be changed as Rob suggested. The first one that comes to mind is the QSQSRVR jobs.

As to the question "should I bother?", that depends. Many of the performance experts will move specific jobs in QUSRWRK and QSYSWRK into a shared pool from *BASE. Usually these are the database server jobs that provide DB/2 access and SQL interfaces. If those jobs are pushing the paging and faulting in *BASE then they should be moved. If you don't have much activity there, it might be a good learning experience but not affect the overall performance of the system.

With respect to work management links, System i NEWS has published a couple of articles I have written as well as a few very good articles by other authors. Search those archives. The IBM documentation for work management is very good, so check that out. If you are near Anaheim CA in early May (6-9) you can meet most of the IBM and other performance experts at the COMMON Annual Meeting.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 1/24/2012 7:54 AM, rob@xxxxxxxxx wrote:

Probably is your routing entries.

DSPSBSD QSYSWRK
7. Routing entries
Pool identifier . . . . . . . . . . . . . . : 2
This should match the number in
2. Pool definitions
not the number in WRKSHRPOOL.




Rob Berendt
-- Group Dekko Dept 1600 Mail to: 2505 Dekko Drive Garrett, IN 46738 Ship to: Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com From: Gqcy <gmufasa01@xxxxxxxxx> To: midrange-l@xxxxxxxxxxxx, Date: 01/23/2012 06:02 PM Subject: carve out QSYSWRK it's own (shared) memory pool Sent by: midrange-l-bounces@xxxxxxxxxxxx has someone done this? Should I not bother? the jobs don't seem to run in the SHRPOOL i set up... (probably the RTG entries???) can you post some of your coolest work management links?
--