Re: Batch Job(s)

Doug,

I'll second John's input.  Although he really doesn't need a second! <g>

Think about this .... a SHARED memory pool.  It boils down to where you want to
control the activity.  Three job queues with one job max each or one job queue 
with
three jobs max, one per priority.  Same pool, same difference.

In our little world we chose one "active" job queue (QBATCH) although multiple 
job
queues may submit jobs to it.  We use a lot of job schedule entries in the other
queues.  They submit to the single "active" queue.  During the day users submit 
to
the active queue (QBATCH) which has one active per priority, three max for the 
queue,
and applications are designated their own priority.  GL, the "head honcho",  
gets #1
where table print outs get #9.  Everyone lobbies for pecking order in between.  
At
Xpm, the sysopr queue submits a job at priority 9 to change the main (QBATCH) 
queue
to one active, letting all current submissions finish, then submits, at #9,  our
daily backup, then submits a change back to 3 active jobs. We also have other 
queues,
like "DAILY",  "MONTHEND", "SUNDAY", "MONTHSTART" that do their own submissions 
to
the single active queue.

Just as a little pointer that I have not seen posted here before, within a job
schedule entry you can have an ADDJOBSCDE.  This allows us to shift some of your
"MONTHEND" job schedule entries to a single  execution of a SUNDAY job.  So we 
do a
ADDJOBSCDE with execution every month end that does nothing more than a 
ADDJOBSCDE
entry for a single execution on Sunday. This way we move some jobs to the first
Sunday of the month.  Since the plants are closed then we do the bulk of our
housekeeping then. No special programming.  A 24/7/365 shop more than likely 
needs
something more robust than what is available with the OS.  There is no reason 
that
one could not program a schedule entry that checks the day of week and adds a
schedule entry to execute on the third Thursday if that's what you needed.

Now the down side is that the only schedule entries in QBATCH are the ones 
submitted
by IBM's backup or power off/on schedule.  You must document that there are 
other
queues submitting jobs to QBATCH.

James W. Kilgore
email@James-W-Kilgore.com

John Earl wrote:

> Doug Barnes wrote:
>
> > Which would be more efficient A or B?
> > A - 3 "batch" subsystems using a shared memory pool. Each SBSD with one 
>JOBQ.
> >
> > B - 1 "batch" subsystem with 3 JOBQs associated with it using same shared
> > memory pool.
> >
> > Both scenarios would have MAXACT set to 1 for each JOBQ.
>
> As long as they are both using the same shared memory pool, their would not be
> any differences in efficiency.  If you wanted to be able to control the
> subsystems separately, then I would use three subsystems.   If you wanted to 
>keep
> things simple, then just use one.
>
> jte
>

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