Re: 400 Disk Storage Crisis

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