RE: Question about subsystem pools -- MIDRANGE-L

An interesting variation of this is to put the subsystem monitor jobs into
their own shared pool.  This has a small but noticeable impact on job
initiations if there's a lot of activity in the base pool.  If the monitor
jobs have their own pool with a sufficient size, they don't get swapped out
to virtual storage and consequently don't need to be paged back in when
they're required.  This is especially helpful if you have a lot of users
with group job capabilities - their group jobs start with fewer demands on
system resources, hence more quickly when the box is busy.  (Note: I got the
idea for this from Richard Jackson, who has no doubt forgotten more about
system internals than I'll ever know.)

I've found that on a system with a lot of activity, it's best to move
everything possible out of the base pool, so that only the immovable system
jobs are left in there.  It seems to make a machine more resilient under
load.  That batch job that reads and updates 2 million records may not run
any faster, but the 0.8-cpu-second picklists and the casual user inquiries
seem to get in and out better, even when the monster is running.

Dave Shaw
Spartan International, Inc.
Spartanburg, SC

> -----Original Message-----
> From: Chris Bipes [mailto:rpg@cross-check.com]
> 
> The subsystem monitor job, i.e. the subsystem runs in memory 
> pool 1 always.
> Based on routing entries, you can place the application work into the
> appropriate memory pool.  It is best not to have your 
> subsystem taking up
> resources you intended for the application to have.  I try to 
> define all
> subsystems with pool 1 as *BASE and Pool 2 as necessary.  If 
> you look at the
> routing entries for QINTER and QSPL and you will see them 
> using Pool 2.  You
> can then control what happens to a job that is reaching the 
> end of its time
> slice.  
> 
> Christopher K. Bipes   mailto:ChrisB@Cross-Check.com
> Sr. Programmer/Analyst         mailto:Chris_Bipes@Yahoo.com
> CrossCheck, Inc.       http://www.cross-check.com
> 6119 State Farm Drive  Phone: 707 586-0551 x 1102
> Rohnert Park CA  94928 Fax: 707 586-1884
> 
> If consistency is the hobgoblin of little minds, only 
> geniuses work here.
> Karen Herbelin - Readers Digest 3/2000
> 
> 
> -----Original Message-----
> From: Allen, Stuart [mailto:sallen@fellowes.com]
> Sent: Friday, April 14, 2000 7:40 AM
> To: 'Midrange'
> Subject: Question about subsystem pools
> 
> 
> In the subsystem description for QINTER, it shows as
>  Pool        Storage     Activity 
>   ID        Size (K)      Level   
>    1           *BASE              
>    2       *INTERACT              
> 
> Shouldn't this subsystem only go into *interact?
> 
> Also, my QSPL sbsd shows:
> 
>  Pool        Storage     Activity 
>   ID        Size (K)      Level   
>    1           *BASE              
>    2          *SPOOL              
> 
> Again, shouldn't this just be *spool?
> 
> 
> Anyone have any ideas?
+---
| 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
+---