If you don't like the prospect of taking down DFHSM to reorganize when a
DFHSM xCDS file gets short of space, then the number of deleted records
is irrelevant. You have already proved by empirical evidence that in
the time you have been running DFHSM the activity against the BCDS is
such as to require corrective action. If you want the interval of time
before the next time you are forced to reorganize to be potentially
longer, then you really want to increase the size of the BCDS. If you
suspect or know there is a growth in the number of actual records, then
you need to increase the size just to avoid having a shorter interval
before the next reorganization.
Because of known growth and a dislike of unscheduled DFHSM loops, we
usually take a very conservative approach to estimating space
requirements for the DFHSM xCDS datasets: when a warning message starts
coming out, we decide what target percentage of occupancy is desired
(obviously you want this below the warning threshold) and allocate a new
dataset allocated proportionally based on the current tracks in use - in
other words, we pretend that reorganization will gain back no space.
Our object is to have the target percentage be the high-water mark AFTER
an equivalent period of activity has occurred. We set the DFHSM warning
thresholds sufficiently low that we know we can easily run well past the
next scheduled IPL without reaching 100%, so when the next warnings do
start coming out we have great freedom to choose when to do a reorganize.
CI freespace can avoid CI splits; but as long as there are still free
CIs in the current CA, CI splits in a KSDS VSAM file are relatively
cheap. On the other hand, CI freespace costs you performance by reducing
the amount of useful data that gets read when you read a DATA CI of a
reorganized KSDS and by increasing the number of DATA CIs that must be
read to process the entire file.
CA splits are expensive (half a cylinder's worth of DATA CIs must be
moved somewhere else!). On modern DASD where 3390 cylinder boundaries
are almost irrelevant in determining physical access delays, CA
freespace costs some DASD real estate but basically costs virtually
nothing in terms of performance (unused data CIs are never read). But,
having unused CIs in a CA (CA freespace) can improve performance by
avoiding expensive CA split operations.
For these reasons I would recommend 0% CI freespace, but some percentage
of CA freespace sufficient to hold down the number of CA splits to
"acceptable" levels. Let VSAM introduce CI freespace through CI splits
at the points in the file where update activity is occurring, so you
only pay the penalty for CI freespace in the places it is needed.
If your primary objective is to minimize the amount of DASD allocated
for the file, and if you have good reason to believe there are
significant portions of the file that have no record insertion activity,
then it may make sense to use 0% CA freespace. This means you must
expect to pay a performance hit for insertion activity after the file is
reorganized until enough CA splits have occurred to introduce CA
freespace in the parts of the file undergoing insertion activity. If
insertion activity is actually uniformly distributed across the entire
file, then over the long run 0% CA freespace will not reduce space
requirements but only hurt performance.
O'Brien, David W. [C] , NIH/CIT wrote:
You might want to do a Listcat of the BCDS to see how many deleted records are
reported. This will indicate whether you need to re-allocate as John suggested
or whether a simple Export/Import will do the trick.
Freespace may also be an issue. For a busy shop Mainstar recommends 50, 50 to
eliminate/reduce CI and CA splits.
At this shop I run with 0,0 and re-org once or twice a year.
-----Original Message-----
From: willie bunter [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 03, 2006 7:24 AM
To: [email protected]
Subject: DFHSM - BCDS QUESTION
I received a message saying that "*ARC0909E BCDS CONTROL DATA SET IS ABOUT 097% FULL ". I
queried DFHSM and no tasks were held. It was also in the process of doing a backup of the bcds &
ocds. I looked at the doc "DFHSM STORAGE ADMINISTRATION REFERENCE" but it did not have the
error message. I know that the message is self explanatory, but I would like to know what action I
should take to bring down the percentage of the BCDS. I know a reorg may need to be done, but so far I
haven't found the job that performs it.
Can anybody please advise me as to what course of action I should take?
Thanks in advance
...
--
Joel C. Ewing, Fort Smith, AR [EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
