An additional secondary allocation is needed for the file, but no space
is available...
Well, you may need to make more space available -- it may be that the volume(s) on
which the file was allocated became full of extents belonging to this and/or other
datasets.
To correct this, you may be able to use IDCAMS DELETE to remove datasets that
are no longer needed, thus freeing space for the catalog itself to grow. You may
be able to allocate additional volumes for the file in question -- the IDCAMS
ALTER datacomponentname ADDVOLUMES... command function can do this for you.
BUT... it may be that:
- Your file is very dynamic and uses keys that are
system or application generated in a continually increasing manner
- Your file has a high percentage of CI and/or CA freespace defined
at load time
- The insert activity for the file causes CI and CA splits, which
essentially add additional freespace, but that additional space is
not usually needed for additional inserts that would fall into the
same range of keys as the CI where the split was triggered.
Thus there is much more space required
than the number of records would seem to demand.
An additional secondary allocation is needed for the file, but no more
extents can be allocated since 123 extents have already been allocated...
You'll have to redefine the file with larger allocation amounts, since
123 extents of the size you've allocated is not enough space for the catalog
itself.
Again, it is possible that the additional allocations are needed, not because
of the number of records in the file, but because the allocation amounts and
other parameters that control how VSAM allocates and uses space for files are
set improperly.
The most common case for this seems to occur because a file has grown
beyond its initial design. You should ensure that primary and secondary
space allocation amounts are appropriate for the actual file's requirements.
It is often the case that secondary space allocation amounts are too small.
Consider ensuring:
- Primary and secondary allocation amounts should be at least one cylinder
in size for any file larger than a few tracks in size.
- Primary and secondary allocation amounts might be chosen to be on the
order of 1/10th of the total size of the file for files less than a volume
in size.
- Remember that the first allocation for a file on any volume will be the
size of the primary space allocation, and any additional allocations will be
the size of the secondary space allocation. It's not inappropriate to have
the secondary allocation size larger than the primary allocation size if that
permits allocations to fill volumes better.
- RAMAC Virtual Array DASD, and similar log-structured subsystems will not
waste real disk space for disk tracks that are left empty. Why not let this
technology simplify your allocations if it is available to you?
One of the above cases seems to be indicated, but only a few records
(relative to the space allocated) are actually loaded in the file.
The file may have been in use for some time,
INSERTing and DELETEing records, and there's never more
records defined than could easily fit into the space available.
You've run into the problem that happens because of the index structure of
VSAM KSDS. When a KSDS is loaded, a range of keys is allocated to each
control interval, and that space within each CI will not be used for
records with keys outside that range, even if there are no records left
in the control interval.
This problem occurs regularly when you all (or significant) insert activity
occurs at a limited number of places in the file. The typical example is in
a branch banking scenario, where each branch has its own range of account
numbers (file keys), and each new account opened in a branch has a key value
just larger than the previous account opened. (The worst case scenario is
where there is essentially only one branch, and all inserts into the file
occur at one point. The insert "hot spot" need not be at the end of the
file, but can be located anywhere within the range of keys for the file.
What should you do about this, when you cannot change the way the keys
are created?
One thing that's simple to do is to reorganize the file. User applications,
system utilities, SORTs, and IDCAMS REPRO can be used as a reorganization
tool.
I recommend that you consider reorganization, and use it regularly to
reorganize your files when you have keys which have this behavior.
Reorganization can be of help, but careful design based on observed use
patterns may be better yet. See the question that discusses reorganization.
You might evaluate how much space -- primary and secondary allocations,
CI and CA freespace -- a file needs to have for a month of
activity, and then arrange for a weekly reorganization, thus keeping far from
the file's capacity limits. Similarly, you might consider providing enough
space in the file for three month's activity, and reorganize the file once
a month.
Reorganization should NOT be performed because some number of CI
or CA splits have occurred. The CI and CA split process creates free space
within a file at the point of insertion. If there is single or multiple
"hot spots" for insertion, CI and CA splits can be a very efficient way to
get appropriate free space generated within a file. Too-frequent reorganization
in these cases would simply eliminate that free space that could have been
used by additional insert activiity.
