There are several unrelated conditions that can cause a catalog to become full.

The simple cases occur when there are many datasets defined in a catalog, but the vexing case occurs when there are relatively few (perhaps less than a hundred) datasets defined within the catalog.

Note that this may be essentially the same problem as discussed in the next question about why files may take much more space than estimated.

First, let's dispose of the cases from most obvious to least obvious:

• An additional secondary allocation is needed for the catalog, but no space is available...

  Well, you may need to make more space available -- it may be that the volume on which the catalog was allocated became full of extents belonging to 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.

  BUT... it may be that your catalog is very dynamic and uses cluster or component names that are system or application generated, and there is much more space than the number of datasets would seem to demand. If this is the case, see the third item in this answer.

• An additional secondary allocation is needed for the catalog, but sixteen extents have already been allocated...

  You'll have to redefine the catalog with larger allocation amounts, since sixteen 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 files or datasets defined in the catalog, but because the cluster and/or component names are continually increasing in value. If this is the case, you should see the next item in this answer.

• One of the above cases seems to be indicated, but only a few datasets are defined in this catalog.

  The catalog may have been in use for some time, DEFINEing and DELETEing datasets, and there's never more datasets defined than could easily fit into the catalog space available.

  You've run into the problem that happens because a catalog is, in fact, a 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. Within a catalog, two keyranges are defined.

  • The higher-valued keyrange encompasses keys beginning with x'40' through x'FF', and records with these keys are sometimes referred to as "true name" records. The record key is in fact the name of the VSAM object -- dataset or cluster, component, volume, etc. It is within this keyrange that the usual problems occur.
  • The lower-valued keyrange encompasses keys beginning with x'00' through x'3F', and the records within this range contain the majority of the information maintained by VSAM in a catalog, such as extent information, volume space maps, details of datasets, and so on.

  This problem occurs regularly when you allow VSAM data set components' -- the data and index components' -- names to default to VSAM generated names, or when you specifically create VSAM data set names with similar characteristics. The default names are created from the system's Time-of-Day Clock, and so each time a data set is deleted and defined, new and higher-valued names are generated. The old component records and their names may be deleted, but the space in the control intervals cannot be reused by the new (higher-key-valued) records being added to the catalog. Many automatic processes tend to use some sort of automatic, date and time based name generation, so that the names generated will always be unique.

  One widely used application in VSE environments is the report distribution system, INFOPAC, by Mobius Management Systems, Inc.. This application gives you an install time option to generate its names using DATE/TIME or TIME/DATE ordering. By letting the TIME component of its name be the more significant part of the dataset name, you will tend over time to recycle through the key ranges and reclaim space within the catalog. The DATE/TIME ordering will cause the name values to continually increase, and the catalog space used to manage deleted datasets will never be reused.

  I mentioned INFOPAC here only because its developers were aware of this VSAM characteristic and give the user an option to minimize its impact. You can use the same or a similar procedure to allow your dataset names to cycle through the same range of key values by using similar techniques.

  Recently (early 2002) there were several threads on the VSE-L list which discussed aspects of this, including JCL routines to automatically generate dataset names for automatic FTP processes and the like.

  Note that even if you've re-used the same -- identical -- cluster (or dataset) names over and over, if you have not explicitly defined the component names for the cluster, you can encounter the same problem, as VSAM generated names for those components will continually increase and eventually cause the same problem.

  What should you do about this, when you cannot change the way the names are created?

  One thing that's simple to do is to exploit the catalog reorganization function of IDCAMS REPRO. When REPRO's input dataset is a catalog, and its output dataset is a sequential file or ESDS, the catalog's records will be unloaded in key sequence. Then, if that sequential file or ESDS is used as the input file, with the catalog itself as the output dataset, the catalog will be reorganized and the space will be reclaimed and made available for additional catalog entries.

  Catalog REPRO is very quick, as it only processes the catalog records, not the datasets defined by those records. The total amount of data involved is small.

  I recommend that you consider this function, and use it regularly to reorganize your catalogs when you have dataset and/or component names which are automatically generated. You will need to quiesce those subsystems which use datasets within the catalog being reorganized, but this should be of small impact since the process can be so quick.

  You might evaluate how much space a catalog needs to have for a month of activity, and then arrange for a weekly reorganization, thus keeping far from the catalog's capacity limits. Similarly, you might consider providing enough space in the catalog for three month's activity, and reorganize the catalog once a month.