Re: JOBS REMAIN IN EOJ STATUS FOR LONG TIME

Another thought. Is this job creating a job log you A) don't need and B) don't want?
If so check the job description to be sure you are not creating job logs for these jobs.

Check to see the allocation for spool files. Is it large enough for the spool files or are you reclaiming all the space constantly so the system has to make room for the spool files being created?

Is there enough memory in the shared pool that runs the job? Once a job goes to EOJ it's priority in the system drops to "when I get around to it" and the system moves on to other active jobs. Memory will have an effect on that process.

Is there enough activity level in the shared pool where the job runs?

These are the first set of basics I would look at.

Rob is also correct that opening/closing files takes a great deal of time. Can these jobs be architected so they are running in a similar fashion to a data queue processor? The job sits there waiting for work, a queue entry comes in, the job processes the queue entry and then waits for another one. This way the files remain open, the entire job structure stays in place and does not need to be created/destroyed 400 times.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 11/5/2013 6:08 AM, rob@xxxxxxxxx wrote:

One might think that 2 seconds isn't a long time, but with 400 jobs I can
see how that adds up.

Just to be clear, you're talking about one job does it's work, comes to
it's end, goes into EOJ status for about 2 seconds, and then the next job
can finally start, right?

Can you come up with a very simple job and see if that job also takes two
seconds? Here's an example of a very simple job:
SBMJOB CMD(SNDMSG MSG(TEST) TOUSR(QSYSOPR)) JOB(TEST)
To test a string of them try
HLDJOBQ...
and submit 10 of them. Then release the job queue.
Now, if they are not tying it up for 2 seconds of EOJ then perhaps the
original jobs are opening a lot of files without closing them, starting a
number of activation groups or any other errata that is cleaned up at EOJ.
If, however, even the test is taking a long time then perhaps it's time to
evaluate your system performance. If adjusting memory and whatnot you may
need to bust out the checkbook for a hardware upgrade. Assuming you are
on our calendar year the sooner you get on this the better so that your
management can get it in the budget for next year.


Rob Berendt
-- IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive Garrett, IN 46738 Ship to: Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com From: Asami_Kaga@xxxxxxxxxxxx To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> Date: 11/05/2013 04:06 AM Subject: JOBS REMAIN IN EOJ STATUS FOR LONG TIME Sent by: midrange-l-bounces@xxxxxxxxxxxx Hello. We add about 400 jobs to job queue. And each job runs sequentially. A job starts at 16:00:00 and ends at 16:00:00. But next job starts 16:00:03. JOBS REMAIN IN EOJ STATUS What does this job do? Why doesn't this job start soon? How can we investigate ? ---------------------------- Asami Kaga.
--