I'm somewhat amused at all the difficulties people seem
to be experiencing with DB capacity management, and DBX.
I guess we aren't quite as big a shop as most (we have about
130 or so data bases, and the largest set among them is only
about 3 million entries (roughly 2.5 million sectors)).
 
For some years, I have been managing capacity (both master
AND detail) by running a weekly job using MPEX's 'db'
format of LISTF output; i.e.,
 
    if finfo ('caprep','exists') then
         purge caprep
    endif
    file caprep=caprep,new;rec=-80,16,f,ascii;disc=nnnn;nocctl;save
    listf <dbname>@.<group>.<account>(dbsetfullness>.75),db;*caprep
 
with the last line repeated in a number of variations to pick up all
databases on the system.
 
I then print the report and take it home with me every weekend.
Sunday morning, 5 a.m., is the BEST time to adjust capacities!
Even our Emergency Department can usually tolerate a few minutes
off the system at that time, allowing me to make whatever adjustments
might be necessary.  Using the well-beloved ADAGER of course.
 
I have recently expanded the program to remind me about certain
flat and KSAM files that are critical to our operations.
 
And (why are system managers so distrustful?), I occasionally
run a program to list all database root files on the system,
just in case someone creates a new one without telling me about
it.  (MPEX again, searching for file code -400).
 
All this is easy (but of course requires both MPEX and ADAGER).
The only time I've been caught out is when developers create a
new database with unrealistic initial capacities, or a new
project involves high-volume data-entry to an existing set that
upsets my records of average weekly increase.  Both have happened,
but extremely rarely (like less than once per year).
 
So why use a sledge-hammer to chase a fly?
 
Ron
[log in to unmask]