|
Generally speaking, control by job queue for sequence (job a has to finish before job b starts) and control by subsystem for performance. > -------- Original Message -------- > Subject: RE: Compiled Programs stuck in QBATCH > From: "Brian Piotrowski" <bpiotrowski@xxxxxxxxxxxxxxx> > Date: Thu, December 08, 2005 1:29 pm > To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx> > > Thanks to everyone who responded. > > I had a quick look at the job queue and there are currently 48 queues on > the system. Out of those queues, 22 of them run through QBATCH. > > Does that sound like overkill? If so, should there be a specific way I > should split up the jobs? > > Thanks! > > Brian. > > -----Original Message----- > From: Barton, Mike [mailto:Mike.Barton@xxxxxxxxxxxxx] > Sent: Thursday, December 08, 2005 10:56 AM > To: Midrange Systems Technical Discussion > Subject: RE: Compiled Programs stuck in QBATCH > > >A few weeks ago, I created a new batch area and assigned a scheduled > job to >it. However, now I notice that whenever I try to compile > programs from the >programmer menu (via the "14" command), the program > will go to the QBATCH >job queue and sit there indefinitely. Here is an > example of the current >job queue when I look at it: > > This is similar to something I noticed on our 400 (this is a development > box only). > > QPGMR (Jobq) had over 50 jobs (all from Job scheduler) released but > nothing happening. > Doing a WRKJOBQ Q* showed the job q allocated to QBATCH subsystem > which has MAXACTJOB=8 so this wasn't the problem. > > Only odd thing I found was that the Jobq also appeared as an entry > in subsystem QPGMR which wasn't active. > Remember tho' that the Jobq said allocated to QBATCH sbs so this should > be ok. > > Removing the Jobq entry on QPGMR and then re-starting QBATCH started > the jobs in QPGMR moving again. > > HTH > > Mike > > -- > > > > -- > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing > list > To post a message email: MIDRANGE-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/midrange-l > or email: MIDRANGE-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. > > > > -- > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/midrange-l > or email: MIDRANGE-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l.
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.