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