|
STG(*FREE) was something that gave us faster restore on the System/38. The idea is to leave the object description, but obliterate the bulk of the disk space. Al Al Barsa, Jr. Barsa Consulting Group, LLC 400>390 "i" comes before "p", "x" and "z" e gads Our system's had more names than Elizabeth Taylor! 914-251-1234 914-251-9406 fax http://www.barsaconsulting.com http://www.taatool.com http://www.as400connection.com Al Mac <macwheel99@sigec om.net> To Sent by: midrange-l@xxxxxxxxxxxx midrange-l-bounce cc s@xxxxxxxxxxxx Subject 400 Disk Storage Crisis 11/06/2005 02:19 PM Please respond to Midrange Systems Technical Discussion <midrange-l@midra nge.com> 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. Specific error messages include: CPI099C Critical storage lower limit reached (latest 11 am) CPF0907 Serious storage condition may exist. (may ... it DOES) There is reference to STG(*FREE) I do not recall what that does. There is something we can do to recover disk space from deleted spool I think the unplanned IPL may have done that 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 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. I have been looking in various libraries to see if their sizes seem normal. 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 . Looks like it happened about 2 am when nasty storm (tornadoes) swept thru our area with power outages. We do have a UPS but I have not recently checked it. It should have been checked when we did a relocation a few months ago. 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. 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. 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. > Display System > Status WIRE 400 > 11/06/05 > 13:21:59 > % CPU used . . . . . . . : 1.2 Auxiliary > storage: > % DB capability . . . . : .0 System ASP . . . . . . > : 29.36 G > Elapsed time . . . . . . : 00:00:01 % system ASP used . . > : 99.5090 > Jobs in system . . . . . : 1018 Total . . . . . . . . > : 29.36 G > % perm addresses . . . . : .015 Current unprotect used > : 720 M > % temp addresses . . . . : .134 Maximum unprotect . . > : 728 M > > > System Pool Reserved Max -----DB----- ---Non-DB--- > > Pool Size (M) Size > (M) Active Fault Pages Fault Pages > 1 75.14 42.37 +++++ .0 .0 .0 .0 > > 2 97.19 .38 34 .0 .0 .0 .0 > > 3 207.81 .00 14 .0 .0 .8 1.7 > > 4 3.83 .00 5 .0 .0 .0 .0 > > > Critical storage condition > exists. - Al Macintyre http://www.ryze.com/go/Al9Mac BPCS/400 Computer Janitor ... see http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html -- 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-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.
midrange.com
