RE: 400 Disk Storage Crisis -- MIDRANGE-L

If you can, I'd bring the system to a restricted state, the do a
RCLSPLSTG *NONE. This will slow your system down when you put it back
into production, but at least it may buy you a few mb so you can do a
RTVDSKINF to see the culprit. Applying all PTFs *PERM will buy you some
disk space. You could do a RCLSTG if you have time. 




Mark Walter
Senior Programmer/Analyst
IBM Certified RPG Developer
Hainey Business Systems
(717) 718-9601 x7148
mwalter@xxxxxxxxxxx
http://www.hbs-inc.com
 

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Al Mac
Sent: Sunday, November 06, 2005 2: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
--
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.