RE: Running batch jobs in Qinter

[Jeff Bull <Jeff.Bull@xxxxxxxxxxxxxxx>]

I may be wrong, but I'm quite sure that I'm not ...

The regular QINTER interactive jobs enter the subsystem via the workstation
entries, NOT the QINTER job queue. I run my system without any job queues in
QINTER.

Now then, when interactive jobs transfer between subsystems (TFRJOB), they
need a JOBQ to achieve this;
so if you need interactive jobs to TFRJOB into QINTER, you will need a job
queue there for them.

To re-iterate my earlier point, the job queue entries in QINTER are rarely
if ever used, so removing them should not be a problem.

Jeff Bull

-----Original Message-----
From: PaulMmn [mailto:PaulMmn@ix.netcom.com]
Sent: 12 December 2002 16:37
To: midrange-l@midrange.com
Subject: Re: Running batch jobs in Qinter


Please remember--  if you place jobq QINTER on hold, no new
interactive jobs will start until the queue is released.  Interactive
jobs use that job queue!

re: more job queues--

We had problems with people submitting a whole bunch of jobs on hold.
These would sit on the job queue until they needed to run one, then
they'd release a job (that could be several days old).  Because the
job had a lower job number than the current jobs, their job would pop
to the top of the job queue, and would run next.  This, of course,
would upset the other users, who would now be behind a (probably)
long running job.

Even if they didn't place their jobs on hold, users could still clog
things up by submitting a slew of jobs at once, which would run one
after the other and clog things up for other users.

We did 2 things:  Each user has their own job queue.  Our routing
programs create these queues automatically the first time a user
submits a job.  The queues are not deleted until the user profile is
deleted.  Jobs for each user are re-routed to their individual job
queues.  Each queue can run only a single job at once.

Next problem is how a subsystem processes job queues.  The subsystem
looks at the list of job queues, and checks job queue #1 for jobs,
which are run.  Once queue #1 is empty, the subsystem looks at job
queue #2.  Once queues #1 -and- #2 are empty, job queue #3 is
processed.  If your job queue is #745, your job may -never- run!

Our routing programs change the subsystem description as each job is
executed:  the queue that a job executes from has its sequence number
changed to the highest number +1.  We have a data area that holds the
next number to use, so we don't have to keep checking.  When the
sequence number reaches the 9000 range, we run a job that resequences
all of the queues back to low numbers so we don't run out of numbers.

The combination of these fixes means that no single user can clog up
the entire subsystem, and each user gets a fair chance to have their
jobs run.  Of course, we have some dedicated queues and subsystems
for things like packing sets &c.

This may seem like a lot of effort, but it eliminates fighting for
low numbered queues, and prevents 'queue hogs' from clogging things
up.

--Paul E Musselman
PaulMmn@ix.netcom.nospam.com





"Alison Sherman-2270" <Asherman=Xb4n7dgmo4+Zox4op4iWzw@public.gmane.org>
wrote:
>  > HI I would like to know if there is a way to disable batch jobs
>from running in Qinter.
>
David replied:

>A long time ago I had that problem ... the solution was quite simple.  Put
>the QINTER job queue on hold.
>
>Jobs would enter the queue, but never go active.  Interactive jobs were not
>affected.
>
>This has the added benefit of allowing me to determine WHO was doing this
>and determine WHY.  Turns out that most people who were doing this needed
>the ability to get a batch job expedited.  The root problem was solved by
>creating a number of separate job queues that they could use when something
>had to get out quickly (these were for order entry, invoicing, and shipping
>departments).
>
>david
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


________________________________________________________________________
This e-mail has been scanned for all viruses by ITM. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe,
email marketing@itm-group.co.uk
ITM - Managing Communication and Information through technology
________________________________________________________________________


DISCLAIMER

Any opinions expressed in this email are those of the
individual and not necessarily the Company. This email
and any files transmitted with it, including replies and
forwarded copies (which may contain alterations)
subsequently transmitted from the Company, are
confidential and solely for the use of the intended recipient. If you are not 
the intended recipient or the
person responsible for delivering to the intended recipient,
be advised that you have received this email in error and
 that any use is strictly prohibited.

If you have received this email in error please notify the IT
manager by telephone on +44 (0)870 871 2233 or via
email to Administrator@itm-group.co.uk, including a copy
of this message. Please then delete this email and
destroy any copies of it.

________________________________________________________________________
This e-mail has been scanned for all viruses by ITM. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe,
email marketing@itm-group.co.uk
ITM - Managing Communication and Information through technology
________________________________________________________________________