RE: "Manage jobs" uses 1/3 of System ASP (28GB) - how to clean up?

["Gary Monnier" <gary.monnier@xxxxxxxxxxxxx>]

Lukas,

It may not be what you are seeing but I've seen client-side applications
do something similar.  When SQL is used, database modifications stay in
"temporary storage" until a commit is performed.  If commits are not
done by the client-side application in a timely manner a system can shut
down due to lack of disk space.

You can reasonably determine which jobs are the culprints by running
DSPJOB with OPTION(*OPNF) against all QZDASOINIT jobs.  Additionally, if
there is a lage number of QZDASOINIT jobs you may want to use paramter
OUTPUT(*PRINT) and review the spooled files.  

Jobs you see with repeating sets of open files are candidates for
further investigation.



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Lukas Beeler
Sent: Friday, July 18, 2008 8:36 AM
To: Midrange Systems Technical Discussion
Subject: "Manage jobs" uses 1/3 of System ASP (28GB) - how to clean up?


Hi All,

I've ran into a rather interesting situation today at a (possible) new
customer. He us running a Model 170 with V4R5 and CUM PTF from 2002. As
such, the situation is already very, very bad.

The problem is that his DASD has been slowly filling up, with no idea
how to fix it.

I ran RTVDSKINF and then PRTDSKINF - one third of the 77GB of available
storage is used by "Internal object - Manage jobs" - 28 GB. I've looked
at bigger systems, and not one of that systems is nowhere near the 28GB
utilisation.

I've searched the web for what might causes this value to rise, but
found few hits. An "AS/400 System Operations" Guide was especially
helpful "Shows the amount of storage used to manage jobs".

I've looked at the number of jobs active in the system - the value was
at 26'000, quite much. Most of these jobs where just spoolfiles in
QEZJOBLOG. I've ran a clroutq QEZJOBLOG, and the number dropped down to
600.

When looking at DSPJOBTBL, i saw that there were two job tables, one
with 16MB, another with 10 or so MB. I figured it didn't hurt if i ran a
CHGIPLA CMPJOBTBL(*NORMAL) and then IPLd the system. The IPL took a bit
longer than usual, but as expected, the disk utilization remained
roughly the same.

As the system is running V4R5, IBM Support is not an option. The machine
is running a RCLSTG through the night, but i don't expect that to solve
anything.

I'm all out of ideas - has anyone had this problem before? I'm
suspecting a problem with the operating system, since it's nearly a
decade old by now.

Regards,

Lukas