|
I don't understand. You are going to take all the interactive users in QINTER and assign department 1 to subsystem qinter1 using shared memory pool pool1, assign department 2 to subsystem qinter2 using shared memory pool pool2, and so forth. Why would you do this? Conventional wisdom (or at least _my_ wisdom) says to take all the interactive jobs and put them into one storage pool (regardless of the number of subsystems) and all at the same priority. The reasoning is that the interactive jobs can allocate free space and fault and use activity levels from one large pool - you don't have to carefully manage several little pools. The machine can do a better job of allocating resources than I ever could but it doesn't work if each thing that it is managing is small. If this isn't working for you, what about it doesn't work? What is your symptom. The only times that I have ever seen a problem with this arrangement is when there is some other major tuning faux pax - like batch running with interactive in a tiny storage pool or inadequate activity levels. Or, when the CPU is too small and you are trying to squeeze the last drop of blood from it. Richard Jackson mailto:richardjackson@richardjackson.net www.richardjacksonltd.com Voice: 1 (303) 808-8058 Fax: 1 (303) 663-4325 -----Original Message----- From: owner-midrange-l@midrange.com [mailto:owner-midrange-l@midrange.com]On Behalf Of STEVE FAIST Sent: Monday, August 14, 2000 3:37 PM To: midrange-l@midrange.com Subject: shared memory pools priority How well does shared memory pool priority work and what exactly does it do?? I'm looking at splitting the subsystems up by department, a separate shared memory pool for each and using the associated priority so Performance tuner will be quicker to act with those memory pools with higher priorites. I may be completely off base though. Thanks all Steve Faist Senior Systems Engineer sfaist@longaberger.com +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +--- +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.