On 01/26/2012 01:30 PM, George Rodriguez wrote:
I'm running the export/import process almost daily. It used to run once a
week.
*
*
*George Rodriguez*
*Specialist II - IT Solutions*
*Application Support / Quality Assurance*
*PX - 47652*
*(561) 357-7652 (office)*
*(561) 707-3496 (mobile)*
*School District of Palm Beach County*
*3348 Forest Hill Blvd.*
*Room B-251*
*West Palm Beach, FL. 33406-5869*
*Florida's Only A-Rated Urban District For Seven Consecutive Years*
On Thu, Jan 26, 2012 at 1:19 PM, Schwarz, Barry A<
[email protected]> wrote:
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of George Rodriguez
Sent: Thursday, January 26, 2012 8:18 AM
To: [email protected]
Subject: MCDS Dataset Help
Hi MVSListerv,
I'm confused about the following information, that's display from command
F
DFSMShsm,F CDS:
ARC0101I QUERY CONTROLDATASETS COMMAND STARTING ON
ARC0101I (CONT.) HOST=1
ARC0947I CDS SERIALIZATION TECHNIQUE IS RESERVE
ARC0148I MCDS TOTAL SPACE=648000 K-BYTES, CURRENTLY
ARC0148I (CONT.) ABOUT 81% FULL, WARNING THRESHOLD=80%, TOTAL
ARC0148I (CONT.) FREESPACE=49%, EA=NO, CANDIDATE VOLUMES=0
ARC0948I MCDS INDEX TOTAL SPACE=0010237 K-BYTES,
ARC0948I (CONT.) CURRENTLY ABOUT 025% FULL, WARNING THRESHOLD=080%,
ARC0948I (CONT.) CANDIDATE VOLUMES=0
snip
I guess what has me confused is the 81% full with the 49% freespace...
Makes no sense to me!
Read the description of the message. The % full is based on the last used
RBA while the % free includes all the space after that point PLUS any
unused space before that point. It is similar to the situation in a PDS
where new data will always be added at the end but there can be gas in the
interior.
Can someone tell me how to fix this problem?
What problem do you think exists? Chapter 3 of the HSM Implementation and
Customization Guide has a section on monitoring the CDSs. It tells you how
to reorganize them if you want to recover the unusable free space.
...
Home of Florida's first LEED Gold Certified School
Under Florida law, e-mail addresses are public records. If you do not want your
e-mail address
released in response to a public records request, do not send electronic mail
to this entity.
Instead, contact this office by phone or in writing.
...
You don't necessarily have to reorganize as soon as the threshold
warning occurs, it all depends on growth rate of %full. Check the %full
immediately after reorganize and then watch growth pattern. It will
grow most rapidly the first day, then slow down as CA/CI splits build up
in the most active parts of the MCDS. If it slows down enough that you
are still below 90% by end of a week (there's nothing magic about 90%
either if growth is slow enough), you choices are either to raise the
threshold so it won't complain for a week, or increase the size of the
MCDS by a large enough ratio so that the inverse ratio applied to the
%full after one week would put that value below your 80% threshold.
As the size of the MCDS gets larger with time, odds are a smaller
percentage of records will change in the course of a week and larger
%full thresholds may be appropriate. You can also track the MCDS %full
after reorganize to get some idea of the actual long-term data growth.
I always had enough stuff to do without worrying about dfhsm CDS's, so
my goal was to be able to ignore them except for once or twice a year:
based on empirical data, size them so the initial unused space is
adequate for the desired interval with a month or so of fudge factor,
and then set the threshold limit to warn you when you reach your fudge
factor. And if you over-estimate size, you can just ignore them for a
longer interval.
Just a nitpick about your VSAM cluster definitions in general:
(1) explicitly specifying "NAME" for DATA and CLUSTER components when
you want the standard default ".DATA" ".INDEX" suffixes has been
pointless for decades, just more stuff to mistype or forget to update;
(2) specifying "SPACE" for an INDEX component is redundant because
IDCAMS should be able to calculate exactly what it needs based on the
number of CA's in your data SPACE definition and explicit values tend
invariably to be gross over estimates (e.g.,less than 5 cyls actually
needed for your particular 900 CA file on a 3390); and
(3) changes to VSAM INDEX CISZ default calculation in the last decade
made the rare occurrence where the default was too small into an
extremely rare occurrence. INDEX CISZ really shouldn't be specified any
more unless you have a known case where the default has been proved too
small and part of each CA is unusable, or some explicit requirement for
a specific INDEX CISZ is built into an application (which seems
unreasonable to me since no application code should be messing directly
with KSDS INDEX CI's).
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
