|
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.