Disk space cleanup

http://archive.midrange.com/midrange-l/200111/msg01582.html

I went to IBM school on some of this eons ago but was able to find my notes & extract some pieces of information that might be helpful.
  I have NOT yet tried all these ideas, some of which may be a bit controversial.  There is also the topic of when it is best to schedule some things that can take a loooong time during which no one else able to use the 400.

Useful Commands
---------------------------
Some of these mentioned earlier in this thread
You do know about wild cards? ... key in part of a command with an asterisk
on the end & see list of all commands that start that way ... e.g. DSPF*
Also you know that GO CMDxxx will get you a menu of all commands that contain
the string xxx for example GO CMDSPLF
There are some other key menus & you can get at the big picture via GO MAJOR
or GO ASSIST

CLROUTQ QEZJOBLOG
CPROBJ
DSPJOBTBL
DSPSYSSTS
GO DBMON
GO CMDDSK
GO CLEANUP
GO PROBLEM
WRKDSKSTS
WRKOUTQ
WRKPRB
WRKSYSSTS
WRKUSRJOB *ALL

Key System Values
----------------------------- WRKSYSVAL
QPFRADJ
QPRBHLDITV
QRCLSPLSTG
There's lots more, but these are ones that I think might be relevant to this
thread

Clean Up
-------------
GO CLEANUP program is called QEZUSRCLNP if you want to add function

Computer Manage Itself
-----------------------------------
WRKSYSVAL QPFRADJ then F1 then ask folks here to explain this
This value is discussed in Chapter 14 of Work Management Manual

Data Access Optimization
--------------------------------------
GO DBMON
do not start this then go to lunch - it collects a lot of info in a short time, and is itself resource intensive in gathering the info - 
 someone might have done this in the past & led to disk space consumption ...
 intention is to use Query or SQL to study the data to optimize performance of how we do things.

Disk Objects Inventory
--------------------------------
Do you have artifacts left over from some implementation or conversion effort
that might not be needed anymore?
We have source code on all our software, but there are thousands of programs,
thousands of DDS, thousands of other things ... the odds are that I might
need to access a hundred of these in like the next year, I just do not know
which hundred.
CPROBJ compresses objects that must be on system for those rare times that
someone does need to use them, but in fact are rarely accessed such as source
programs ... think of CPROBJ as being like ZIP/400

Disk Status
-----------------
WRKDSKSTS
each unit should be less than 50% busy - if over 70% we need to use
performance tuning to balance our files

Performance is enhanced if data "balanced" across different hard disks
V4R3 added DSKBAL (via PTF for earlier V's) to do this at IPL time (I betcha
that takes a looong time) V4R4 enhanced this.  See News/400 Dec 1999 tips.

File Size Fluctuation
------------------------------
Files Grow in disk space consumption to accommodate  requirements of the
data, up to some limits that may need periodic review (DSPFD to *OUTFILE &
query compare current capacity with ceiling capacity) but as I get around to
cleaning out dead records, those files are still eating the disk space needed
when their content was inflated, so there may be a need to check & see if
some files have excess capacity, wasting disk space

IPLs
-------
IBM Hardware & OS/400 improvements mean that doing an IPL becomes less & less
useful or neccessary, but there are a few things it does that may be relevant
to helping your situation, with respect to helping you clean up stuff.

For example, if you have some large system logs, IPL ends them all & restarts
them, then you go delete your system logs.  There are some work areas whose
disk space gets cleaned up.

Do you need to IPL?
Look at WRKSYSSTS (all kinds of commands)
What % addresses used? ... if 70-80% you need IPL
What's your % disk space used? ... the higher it gets the more often smart to
IPL

Job Logs
-------------
WRKOUTQ - get list of output queues - scroll & find joblogs
You can delete all joblogs in one command
14 - clear an outq
You do not want to delete the outq
so do not get confused what the options do

I have put CLROUTQ QEZJOBLOG on a menu for purpose of doing this after backup
& after a WRKOUTQ review to see if I need to keep any ... typically I kill
several hundred a day after moving 1-2 a week to another Q for study.

WRKF QHST*
How many do you have?
We have 4 days worth

Message Queues
--------------------------
When full they get extended (more disk space)
When empty they as big as they ever get
to make them smaller you can delete & recreate

Performance Monitoring
----------------------------------
Are there objects y"all finished with?
LIB QPFRDATA

Reclaim Storage
------------------------
If you run RCLSTG reclaim storage, afterwards DSP QRCL & QReclaim directory
to check out the stuff that Reclaim did not know what to do with

Reports clogging Spool
----------------------------------
WRKUSRJOB *ALL & F4 ... try different mixes ... see which users most prone to
leave reports open.

When locating & clearing ancient reports, I favor the end users doing this,
but sometimes they say "Al it is Ok for you to kill ......" certain
categories of stuff, like say file maintenance audit trails that are over a
week old.
I most comfortable with WRKSPLF _______ (name of user) which gets at
everything for that one person where I can put 4-delete in front of many
lines at one time

If you want to have a CL to do some repetitive kills of ancient reports,
check out
CHGSPLFA Change Spool File Attributes
*SELECT lets us select all reports that match criteria such as
USER (name, *CURRENT or *ALL)
PRINTER (specific OUTQ, *ALL)
FORM TYPE (specific or *ALL)
User Data field (specific or *ALL)
so for example, with one command string we can move 100% of one person's
reports from one OUTQ to another or change # copies or save after printing &
etc.

Check the archives for info about shareware to do stuff like killing all
spool file entries that are over some date age for a selected list of users
with some other exceptions

You know when you do display job information on people prior sessions that
created unprinted reports?  There is a certain amount of 400 baggage to keep
track of all that.  It is not just number pages.  If people really need to
keep reports on spool, you might want to explore ways to get that report data
into some other form that gets saved without tying up 400 jobs.

DSPJOBTBL shows how much space has been allocated for keeping track of
multiple jobs on the system & how much of that has been consumed so far.

    From a performance standpoint it is better to not be slowing people down by

the system creating new jobs a lot, as opposed to reusing them, but you also
might not want this sort of thing accumulating indefinitely.  This is a big
subject to understand ... currently I have our values set at what I think is
reasonable, with IPL clearing out some accumulation.

If you have had large #s of deleted spool files, reclaim space via system
value QRCLSPLSTG or perhaps after heavy printing activity such as end-month
do RCLSPLSTG

Security Auditing
-------------------------
Are you doing this?

System Problems
--------------------------
GO PROBLEM & WRKPRB
default shows current list
99% of OUR problems shown here are idiot events outside IBM relevance such as
PC goes down & IBM thinks there may be a hardware problem, or ma bell goes
goes down in weather front & IBM thinks there may be a hardware problem, so
all these incidents get opened that we know are not in IBM hardware & I want
to delete them but they are more days than system value QPRBHLDITV allows so
I need to lower this value to get rid of the garbage then raise it again in
case we ever do have a hardware problem that is IBM

Threads Other
--------------------
See recent midrange-L thread on "deleting logical files"
I may be approaching diminishing returns on my own effort to clean up our
disk space, once I complete the stuff I know needs to be done.