On Wed, 24 Jan 1996 10:16:25 -0800 <Elbert E Silbaugh> said:
>Denys writes:
>this example ... comes at a most opportune time. Tell me, why do I
>feel like a dentist?
>
>Pwobable cauz I fee ike a atient ume imes. :-)
 
Ummm, I would have thought the opposite, if Denys was referring to his
original position.  In any case, getting dbinfo 202 changed is a job for
a dentist since it appears to be as difficult as pulling teeth.
 
On the other hand, for customers that sense pain (unchanged dbinfo 202)
who are afraid of dentists generally stay well away from an appointment
until they can't stand the pain any longer :-)
 
So I suppose either analogy applies.  I agreed with Evan's arguments for
change as well, but for yet another version of the story...
 
We have very few (if any) local applications that check dbinfo 202 for any
critical reasons; we have some of ours and many HP/third-party ones that
use it for "monitoring" database capacity.  We run such utilities on a
weekly basis and look for sets that are filling up.  Even if we see one
that is approaching capacity, you have to plan for exclusive access to do
capacity changes.  These jobs run on the same schedule as the ones that
check free space on our volume sets.
 
With DDX enabled or not, we see the same figures for the data sets with the
current scheme.  With DDX enabled, we get some benefit by insuring we have
disc space available so it won't fail.  But this is a panacea -- now we
don't have an indication of the real "max" capacity of the set, so if we
opt for this mindset we run the risk of ignoring capacity warnings in hopes
we aren't yet at the max DDX capacity.
 
The combination of routine set loading reports (legacy dbinfo 202 with the
suggested modified behavior for max capacity) and the disc free space report
by volume set benefits every application - those using dbinfo or not - and
no code changes necessary.
 
I guess I've beaten this to death.  I'll let it rest until IPROF :-)
 
Jeff Kell <[log in to unmask]>