|
On 11/6/05, Al Mac <macwheel99@xxxxxxxxxxx> wrote: > I am looking for suggestions ... commands to use to see if I am missing > something. I can't run disk space analysis because there is not enough > disk space left to do that, thanks to whatever object(s) I trying to > locate, that's responsible. Almost certainly the runaway job did it. Check if it built any large temporary files somewhere, or find the job log. > QHST05296A ... I assume this is system history from 2005-10-29 > QHST05*** various #s onwards ... can I safely delete the smaller # ones? > Well I took the plunge and deleted some of the oldest ones, as indicated by > WRKOBJ QHST* then view with 8 Yes, you can delete any that are before the last backup. Speaking of which, why such infrequent backups? > I have been looking through OUTQ to see if there is any sign of a runway > job, that might have created an infinite sized report & so far not found > one ... in time I will have checked all reports, I also killing some audit > trails that are quite old, but that is a microscopic drop in this bucket. After deleting the spooled files you still need to do a RCLSPLSTG to get the storage back. Spool storage works similar to deleted records; the record is gone, but the space is still allocated. > AS/400 Model 170 OS/400 V5R1 > Extremely reliable hardware ... goes for years without any problems, but > have one right now. > The AS/400 is in Illinois 60 miles away from where I am in Evansville > accessing it via VPN, but I am able to get into just about everything by > remote. > > Overnite something has eaten all our disk space, which is now at 99.52% > consumed of 29 Gig John Jones gave you a good list; history logs, journal receivers, etc. Check if the same job ran as on the primary system. Look in QEZJOBLOG output queue for any big spooled files; that might get you the culprit. Do a WRKOUTQ *ALL and clean hours, then a RCLSPLSTG *NONE. > I check disk space regularly (several times a month) ... a few days ago it > was under 65% used, which I consider to be healthy. > I had been working on cleaning out some ancient records because our BPCS > applications were creeping eating disk space ... we were almost up to 80% > consumed, a few months ago. > Normally it never fluctuates by more than about 5 % up and down. > > I was last on the system Saturday nite testing a software modification > (adding something to an inquiry screen). Everything seemed normal then. > I signed on Sunday, because I was going to do a remote backup, and work > some more on some modifications. Last backup was last weekend. > We used to do backups every nite, but getting a window of people staying > off the system on weekdays has become impossible. Unrelated -- Make sure that everyone higher than you on the food chain is aware of the risks of not having daily backups. > This crisis has triggered at least one IPL ... last one round 10 am Sunday. > We have IPL as part of a scheduled shutdown for a few hours every late > Sunday, wee hours Sunday. > GO CLEANUP is scheduled for every morning in wee hours, and it completed in > between these other error messages. > > One thing I suspect is performance tools, which quit working after last > OS/400 upgrade, and I not have any documentation on them. I would like to > know how to kill any data they have collected. I imagine you can delete the library. > We were in process of considering switching hardware tech support place for > our AS/400 (from IBM to ServIT) ... I need to check with my collegue Paul > to get phone # to call for hardware support, and he not home right now. I > probably will head into the local office & get the # to call IBM which I > not been storing at home, and see if we still on that support, after I > exhaust some more things I can check by remote in hopes of finding whatever > the heck it is (assuming it is only one object) that is eating all our > available disk space. This would be software support not hardware support. The phone number for both from IBM is 1-800-IBM-SERV. Good luck -- Tom Jedrzejewicz tomjedrz@xxxxxxxxx
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.