× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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






As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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.