× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



One way to find large unwanted objects is to use the DSPOBJD command for
*all objects in *all libraries and send it to an outfile, then run a query
on that file sorting by object size.  It usually contains surprises.

Jeff

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Al Mac
Sent: Sunday, November 06, 2005 1:19 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 400 Disk Storage Crisis

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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.