System job tables exceeded
s.ca...@nvebs.com
the system does not want to start up I did a manual IPL, It hangs on
the IPL option STARTING System jobs QSYSARB.Do youhave a solution for
me to recover this without restoring the operating system.
Thanks,
Steve
mat.ho...@triangle-group.com
Hi,
If you do a manual IPL one of the of the options that you get after
passing DST, but before you get a command line for the full OS, is to
clear output queues. If you specify that you want to clear all output
queues then the system should start up again.
Thanks,
Mat.
jse...@yahoo.co.nz
As far as I'm aware, this is not recoverable restoring the OSl. An
IPL would not fix this issue as this does not clear the job tables
however, you should have had plenty of warnings in the QSYSOPR message
queue about the work control tables getting full before this occured.
In case you are not aware, when a job is initiated, an entry is
created in the job tables (you can view these by using the DSPJOBTBL
command). When a job ends and all output from it is deleted, the
entry will be removed from the job table. A job table can contain a
certain number of entries before it gets full (16352 by the looks) and
once full the system will create a new one however, it can only create
10 (from memory) at most. Once all the job tables are full, NO NEW
JOBS CAN BE INITIATED. This is why your IPL is stuck - in fact an IPL
was probably a bad move. I have seen these job tables approach limits
before on systems where the OUTQs are not tidied up and reports sit
around for years and never seem to get deleted. I would guess you are
in a similar situation in which case, it is time you looked at
initiating a cleanup of the output queues. Instead of an IPL,
deleting old reports would likely have recovered the situation.
s.ca...@nvebs.com
Hi mat,
Everything is ok,we specified the option clear outqueues.
The system started normally.The only problem is te endusers lost all
there spoolfiles.
But we had no other option.
Thanks anyway,
steve
s.ca...@nvebs.com
There was a batch program the developers tested it didn't work
properly. it was in jobmode.It created more than 160000 jobs in the
jobqueue, thats why the system had crashed, so i didn't had the time
to clear all the jobqueues en spoolfiles it creatend before the
systeem went down.I have to look for a way to prevent this happening
aain when the developers are testing.Do you have an idea?
Thanks,
steve
CRPence
with the situation; e.g. if the identified threshold is far beyond a
previously logged level, it could hold all job queues and terminate all
jobs that recently started [many jobs], and start a few jobs to clear
some job queues and output queues. Also at v5r4m0 review SI29585 for
the ability to get more granularity for the threshold percentage;
allowing for an earlier warning.
kwd: QMAXJOBPCT
Regards, Chuck
--
All comments provided "as is" with no warranties of any kind
whatsoever and may not represent positions, strategies, nor views of my
employer
s.ca...@nvebs.com wrote:
> On Jan 6, 5:22 pm, jse...@yahoo.co.nz wrote:
> <<SNIP>>
> There was a batch program the developers tested it didn't work
> properly. it was in jobmode. It created more than 160000 jobs in the
> jobqueue, thats why the system had crashed, so i didn't had the time
> to clear all the jobqueues and spoolfiles it create and before the
> system went down. I have to look for a way to prevent this happening
> again when the developers are testing. Do you have an idea?
Chris Pando
[system table overflow]
> There was a batch program the developers tested it didn't work
> properly. it was in jobmode.It created more than 160000 jobs in the
> jobqueue, thats why the system had crashed, so i didn't had the time
> to clear all the jobqueues en spoolfiles it creatend before the
> systeem went down.I have to look for a way to prevent this happening
> aain when the developers are testing.Do you have an idea?
Better developers? :)
Chris
--
"... the whole world is a circus if you look at it the
right way. Every time you pick up a handful of dust, and
see not the dust, but a mystery, a marvel, there in your
hand - every time you stop and think, 'I'm alive, and
being alive is fantastic!' - every time such a thing
happens, Mike, you are part of the Circus of Dr. Lao."
Rodney A. Johnson
If you have jobs on the job queue, a Yes answer to Clear Job Queues on
the IPL options screen would have taken care of the problem with NO need
to specify Yes on Clear Output Queues.
Also note that in V5R2M0, the ability to have spooled files live without
the job was introduced. QSPLFACN system value and job attribute SPLFACN
are what control this feature. This feature can be particularily useful
when you have a system with lots of spooled files under jobs named
QPRTJOB. Keep in mind when using this feature that you now have the
possibility of having more then one spooled file where the qualified job
name, spooled file name, and spooled number are the same. At that point
any and all interfaces would be required to use the additional
JOBSYSNAME and CRTDATE attributes to identify which of the spooled files
(that have duplicates of old id attributes) you wish to use.
CHGJOB JOB(../../..) SPLFACN(*DETACH) also works really well at getting
rid of jobs with all spooled files in FIN status.
--
Rodney A Johnson
Technical Team Lead for i5/OS (AS/400) Spool
Dept GJC
IBM Rochester, Minnesota
The contents of this message express only the sender's opinion.
This message does not necessarily reflect the policy or views of
my employer, IBM. All responsibility for the statements
made in this Usenet posting resides solely and completely with the
sender.