Cobol - IBM VSAM parameters was Re: Static or Dynamic Call.

Author

IBM VSAM parameters was Re: Static or Dynamic Call.

Clark Morris

2006-05-07, 6:55 pm

On Sat, 06 May 2006 02:25:19 GMT, "Joel C. Ewing"
<jcREMOVEewing@CAPSacm.org> wrote:

>Clark Morris wrote:
>
>Since at least z/OS 1.4, the algorithm used to calculate the default
>(and minimum) Index CI size was revised so it is now highly unlikely
>that you can even force an inadequate Index CI size to be assigned.
>There is also a PTF available on z/OS 1.6 that enhances the IDCAMS
>utility so that EXAMINE INDEXTEST on a KSDS VSAM dataset will now give
>statistics on how much space is actually used for compressed keys in the
>INDEX -- you no longer need to guess whether INDEX CI size is an issue.
> On current z/OS systems it should rarely, if ever, be necessary to
>specify INDEX CISIZE.

I am glad that they finally did this. My last exposure to an MVS
system was OS390 2.5 or 2.7 and my next assignment was on HP-UX. I
remember reading something about this on ibm-main. I also remember
using a 3rd party utility to clean this stuff up. I think it is
indicative of something that it took 18 - 20 years to address
something that should have been taken care of by 1985.
>
>I also get ticked off at vendor examples that redundantly specify names
>for the KSDS DATA and INDEX components with the last qualifier of
>"DATA" and "INDEX", which has been the MVS default for at least 20
>years; or an explicit INDEX space requirement of CYLINDERS(1) for a KSDS
>with 2 DATA CA's, which only needs a fraction of 1 track for an INDEX;
>or "IMBED" or "REPLICATE" attributes, which have not been recommended
>for 15 years and have been ignored for at least the last 5 years. These
>days, 99% of the time you shouldn't even need to specify an "INDEX"
>section when defining a KSDS VSAM dataset, as the defaults are fine.
>When I see inappropriate or redundant attributes in documentation, its
>tells me the author lacks a basic understanding of current KSDS VSAM
>best practices.

Have there been other changes in VSAM allocation to make it work
better? For example given a record size of 80, what data CA size will
an allocation of 40,000 primary records, 4,000 secondary records give.
It used to make the CA size that of the secondary allocation which is
not what most people would want. It would be nice if the index
component could automagically be allocated based on the number of
records and key length specified in the allocation parameters. I
suspect that change of idiocy in VSAM allocation and the publicizing
of changes so minimal that it has been easy to overlook the
desirability of changing recommendations.

Joel C. Ewing

2006-05-07, 6:55 pm

Clark Morris wrote:
> On Sat, 06 May 2006 02:25:19 GMT, "Joel C. Ewing"
> <jcREMOVEewing@CAPSacm.org> wrote:
....
>
> Have there been other changes in VSAM allocation to make it work
> better? For example given a record size of 80, what data CA size will
> an allocation of 40,000 primary records, 4,000 secondary records give.
> It used to make the CA size that of the secondary allocation which is
> not what most people would want. It would be nice if the index
> component could automagically be allocated based on the number of
> records and key length specified in the allocation parameters. I
> suspect that change of idiocy in VSAM allocation and the publicizing
> of changes so minimal that it has been easy to overlook the
> desirability of changing recommendations.

One of the things still lacking in VSAM KSDS definition is a way
independent of space allocation to force sub-cylinder CAs. If someone,
as in your example, specifies a secondary small enough to force this,
there is no way to guess intent. If you have large, poorly-compressible
keys and some reason you need to constrain the INDEX CI SIZE (say, to be
able to share some buffer pool), then deliberately using a small
secondary to force sub-cylinder CAs and reduce the number of CIs per CA
is the only current way to control this. The real problem is that with
RECORD allocation, the user is "encouraged" to be ignorant of DASD
geometry and may do this unintentionally.

One can't just change the existing CA size computation without adversely
affecting those who are deliberately using current behavior to get
sub-cylinder CAs. What is needed is a way to override current behavior
with a new definitional attribute, say "CASIZE(tracks)", where a value
>= physical tracks/cylinder, like "99", would always force a CA size of
one cylinder. Or, one could introduce a new keyword ("MAXCA"?) that
would always imply a full-cylinder CA and force allocation rounding to
cylinder boundaries. This looks like a candidate for a SHARE requirement
under Storage Management, but I don't know if enough installations would
see the problem as serious enough to warrant giving it high-priority.

As to INDEX allocation, as near as I can tell the default INDEX
allocation has for many years been accurately based on the number INDEX
CIs needed to cover the number of CAs allocated to the DATA component,
and since the INDEX CISIZE also defaults to a reasonable value based on
the key attributes, all should be covered by the defaults. The only
recent cases where I have specified explicit INDEX allocation have been
when I knew the dataset would soon undergo large growth and I wanted to
massively over allocate the INDEX to avoid getting many small,
sub-cylinder INDEX extents contributing to DASD fragmentation. It could
be argued this was done more for subjective, aesthetic reasons than
because of any real requirement.

I have made it a habit over the years to scan through new versions of
manuals to look for changes, read through release migration manuals, and
read DOCS HOLD text for maintenance PTFs. Since I know the troops in
the trenches don't have time to do this, I regard it as part of my job
as a SysProg to look for changes that may be significant to our
installation and publicize them, get local installation standards
changed when appropriate, etc. Even with that effort, there are always
some who never get the word, old stuff that may get cloned by a newbie,
things that may fall through the cracks. IBM cannot instantaneously
review, update, and republish all existing manuals, so bad examples may
persist for years; and I'm sure IBM also has the same problem we do in
keeping all their staff current on topics they may not regard as their
primary area of expertise.

--
Joel C. Ewing, Fort Smith, AR jREMOVEcCAPSewing@acm.org

Sponsored Links