|
V5R4? My customer got up to 98% when a new QHST was being created every 10
minutes or so. Turns out that the logging on Mimix was the culprit. It
also turns out the JDE admin did not run the DSPOBJD on all JDE objects,
therefore, each time an object was used for the first time it got
expanded, therefore changed.
They ran up to 58 GB of space used for temporary objects on a 140GB
machine. I'm having them reboot tonight to get that space back
--
Paul Nelson
Arbor Solutions, Inc.
708-670-6978 Cell
pnelson@xxxxxxxxxx
-----midrange-l-bounces@xxxxxxxxxxxx wrote: -----
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
From: Larry Bolhuis <lbolhuis@xxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
Date: 12/06/2006 04:45PM
Subject: Runaway QHST
Here's a strange one to watch for.
Customer calls wanting disk moved around on a 520 LPAR. They have gone
from 60(ish) percent full to 90(ish) in the last few weeks and dont'
know why. I get there this morning and am also told 'your backup (I
wrote it for them) also failed the last two Wednesdays can you check
that too?'. Sure, so I hit DSPLOG starting at 2 AM After 10 minutes
still input inhibit. Hmmmm. Sysop tells me he quite using DSPLOG because
it takes *WAYTOOLONG. Hmmmmm (again). WRKOBJPDM QSYS/QHST* blows up
with 'too many objects'. Hmmmmmmm! DSPOBJD of QHST* and a query shows
187,000 of them totaling 150+GB. Well now there's the disk space they've
been missing! Oldest file is 30 days old and matches CHGCLNUP values.
Whysomuch? Turns out they had a damaged device description which the
system was trying to vary on, that failed with damage, then it tried to
delete it but the damage made the system think it was already gone, then
it tried to make a new one which failed with 'already there' then it
tried to vary it on which f.... This it did right around 1,500 times
per second, creating a new QHST* file every 2 or 3 seconds. For about
three weeks. The backup failure turned out to be SAVSYS failing with
too much stuff in QSYS!
- Larry
ps: They thought the system had been running a tad sluggish as well. :-)
--
Larry Bolhuis IBM eServer Certified Systems Expert:
Vice President iSeries Technical Solutions V5R3
Arbor Solutions, Inc. iSeries LPAR Technical Solutions V5R3
1345 Monroe NW Suite 259 iSeries Linux Technical Solutions V5R3
Grand Rapids, MI 49505 iSeries Windows Integration Technical
Solutions V5R3
IBM eServer Certified Systems Specialist
(616) 451-2500 iSeries System Administrator for
OS/400 V5R3
(616) 451-2571 - Fax AS/400 RPG IV Developer
(616) 260-4746 - Cell iSeries System Command Operations V5R2
If you can read this, thank a teacher....and since it's in English,
thank a soldier.
--
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-2025 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.