RE: Using Subsystems -- MIDRANGE-L

Jack 

An approach that I used was to create separate jobq and subsystems for each
branch I had. I ended up with 5 subsystems and jobq's, slightly smaller than
your case. Then to avoid having many  jobs in batch all with the same job
priority I created different Classes for each subsystem. The classes I
created were with differently priorities 45, 46, 47 48 49 Plus the standard
qbatch class with priority 50. I then studied work loads ie one branch was
very large and submitted a lot of work while some were small. I then
assigned classes based on the branch with the most importance. It turned out
that  due  to the way the branches work some east coast and some west that I
had some branches assigned the same class (priority) since it was rare that
work from two branches were active at the same time. I did this for a model
F60 with 192 mg of memory. I guess there is many solutions to your problem
but it depends on knowing your work loads as to which is best for you.  

Russ Popeil
Avnet Computer - Integrated Solutions. Bottom-Line Results.
Office: 516-677-9346, Fax: 516-677-0296, Beeper: 516-786-5846
eMail:  Russ.popeil@avnet.com
http://www.ac.avnet.com



> -----Original Message-----
> From: PaulMmn [SMTP:PaulMmn@ix.netcom.com]
> Sent: Thursday, April 16, 1998 9:34 PM
> To:   MIDRANGE-L@midrange.com
> Subject:      Re: Using Subsystems
> 
> >>>> 
> 
>       Jack 
> 
>       At 08:44 AM 4/15/1998 -0500, you wrote:  
>       >>>> 
> 
>               Hello Everybody: 
>                  
>               We operate nine different companies from one AS/400 model
> 500 V3R7.  At a recent MIS department meeting we discussed setting up a
> seperate subsystem for each company so that we can schedule simultaneous
> jobs between companies without scheduling conflicts.  There would be some
> other benefits as well.  My question is, what kind of a performance hit
> can we expect take if we go ahead with these plans?  Most of the companies
> are very small, the largest only has about 30 users. 
>                  
>                  
                        Jack Mullins 
>               Sun Industries, Inc. 
>               <http://www.sundash.com>http://www.sundash.com 
>               <mailto:jmullins@sundash.com>jmullins@sundash.com 
>       
> <mailto:jmullins@hurtcompanies.com>jmullins@hurtcompanies.com 
>               <mailto:jmullins@ipa.net>jmullins@ipa.net 
> 
> 
>       <<<< 
> 
> 
> 
> 
> If you're dealing with dueling batch jobs, one of the problems you may be
> facing is that, given 9 job queues feeding your batch subsystem, the
> System processes the queues in rotation. 
> 
> If jobs are dumped into all queues at the same instant, the system will
> process the first queue in the List of Queues in the Subsystem
> Description.  When a slot for a job opens (unless you have restricted max
> jobs per queue), the FIRST QUEUE will be scanned for ready jobs.  If no
> jobs, Queue 2 will be selected. And so on.  
> 
> The problem is that this scheme gives priority to the FIRST QUEUE!  Queues
> at the bottom of the list will tend to NEVER be processed. 
> 
> Our solution was to create a routing program for our batch subsystem.  As
> each job starts to execute, we issue a CHGJOBQE and change the sequence
> number of the queue the job started from to the end of the list (ie give
> it a high number).  A data area tracks the next available number (with
> error recovery in case someone snuck a queue with that number into the
> subsystem). 
> 
> Actually, we created 2 ranges of job queues:  The payroll set, which
> always has sequence numbers lower than the sequence numbers of the 2nd
> set, for 'routine' batch jobs. 
> 
> The last piece of this solution is a program that gets kicked off to
> re-sequence everything back to 'low' numbers once the sequence numbers
> reach the region of '9999'. 
> 
> This has allowed us to process all jobs from all locations without needing
> to set up separate subsystems; we just allocate memory to the single batch
> subsystem so the number of active jobs we've selected have a good chance
> to run. 
> 
> We've been using this scheme for the past 5 years or more.  It has solved
> the problem of a single queue hogging the subsystem; users no longer
> complain that their jobs never get a chance to run. 
> 
> --Paul E Musselman 
> PaulMmn@ix.netcom.com 
> 
> 
> 
> +--- | This is the Midrange System Mailing List! | To submit a new
> message, send your mail to MIDRANGE-L@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 unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---