IBM Support

IEC331I 020-000(2908001C) - CATALOG CANNOT EXTEND

Troubleshooting


Problem

This document is for informational purposes regarding the IEC331I    020-000(2908001C).   This error indicates the catalog is unable to extend.  This error is described under IDC3009I and cites the following reasons:
  •  There is no more space on the volume on which the catalog resides
  •  The maximum number of extents has been reached (123)
  •  The catalog has reached the 4GB limit
  •  There is not enough contiguous space on the volume (required when the catalog's secondary allocation is defined in tracks).
WHY IS THIS ERROR OCCURRING?

When encountering this issue, first LISTCAT your catalog to determine if you would exceed the 4gb limit upon the next extend
                                                                
LISTCAT ENT(catname) CAT(catname) ALL                          

ALLOCATION                                                      
    SPACE-TYPE------CYLINDER     HI-A-RBA------4035133440       
    SPACE-PRI-----------4975     HI-U-RBA------4035133440       
    SPACE-SEC------------498        
                           

As you can see with this allocation, taking the next extend of 498 Cylinders would have exceeded 4gb (4294967296) and thus   result in the 20-0 error.  It's also important to note what a SPACE-SEC of 0 will remove the catalog's ability to extend at all. This applies to either the catalog's Data or Index components.

If this is not the case, ensure your catalog volume has enough contiguous space to accept the secondary amount quantity and that the number of extents in the catalog will not surpass the 123 limit.

VOLUME                                                          
    VOLSER------------MYVOL1       PHYREC-SIZE---------4096     
      HI-A-RBA------4035133440     EXTENT-NUMBER--------122

At most, an extent amount will be satisfied by DADSM in 5 physical extents.  If your volume has 8gb of free space but the largest free space is only 50 cylinder, you will not be able to satisfy a 300 cylinder extent amount request.  For this reason, we suggest that catalogs be placed on their own volumes to remove the concern of highly fragmented volumes.  Note also that if your catalog has 119 extents and DADSM satisfies the next extent by spreading the allocation over 5 physical extents, that will also surpass the 123 extent limit. 
                        
I HAVE NO PROBLEM DEFINING OTHER DATA SETS TO THE CATALOG, IS THIS STILL MY PROBLEM?
                                                                
A BCS Catalog is a VSAM KSDS.  The data set name is the key used to place the record into the Catalog data set.  As with all KSDS, a key must be placed in a specific CI within the data set.  If this CI happens to be full, the CI must split.  If the CA in which the CI resides is also full, the CA must split which causes the catalog to extend.   If you are able to define a data set of another name, this request is being directed to a different CI or CA that has available space; thus no need cause an extend of the catalog. 
            
A LISTCAT SHOWS I HAVE PLENTY OF FREESPACE, IS THIS STILL MY PROBLEM?

The FREESPC statistic is not accurate for catalogs and you will see it is defaulted FREESPC=HARBA for all catalogs

Resolving The Problem

First, ensure your problem is not caused by other non-catalog data on the volume taking up space.  If so move this data to another volume.

Most common is that your catalog reached the 4gb limit.  The only way to permanently resolve this is via a reorganization of the catalog. A catalog reorg will essentially define the catalog new and reload data back into the catalog.  This process evenly distributes data across the catalog reducing much of the inflation that had occurred over time.  Use steps listed in the
'Reorganizing or Changing the Size of a BCS' section of Managing Catalogs to perform the reorg.

To perform a reorg safely requires significant down time for the procedure unless a non-IBM solution is available to you.  If you are in the position in which a temporary solution is required,  the only options you can take are:
  1. Delete data from the catalog.   This is not guaranteed as you must delete data in the full CI/CAs in order for this to be effective.  There are no IBM analysis tools available for identifying these areas.                                       
  2. REPRO MERGECAT an alias into a different catalog.  This also takes some down time but typically to only a subset of applications using the catalog.  Note that this should be the alias involved in the extend problems.  This will not provide usable space for different keys to use.  See 'Splitting Catalogs or Moving Catalog Entries' section in Managing Catalogs for the proper procedure.
PREVENTATIVE ACTIONS

When you prepare to reorganize you catalog, you can take this as an opportunity to change your catalog characteristics:
  1.  Enable CA Reclaim.  CA Reclaim does not work retroactively so it cannot be used as an existing space problem.  When enabled, it will allow VSAM to recycle previously used empty CAs reducing the need for catalog reorganization.  See Using Data sets 'Enabling and Disabling CA Reclaim'                  
  2. Choose proper secondary amounts to get the most out of 4gb limit.  For instance a 1gb primary with a 2gb secondary allocation will exceed 4gb in the 2nd extend attempt.
  3. Define your Catalog as Extended Addressable.  Catalogs are still limited to single volume, but now have the ability to be defined to an Extended Addressable dataclass allowing them to exceed 4gb.  We suggest this as a measure to avoid space limitations.  If your catalog exceeds 4gbs, you should consider splitting the catalog.  If too many applications are accessing a single catalog, you may become susceptible to unnecessary contention.
Give your catalog its own volume.  Since catalogs can only reside on a single volume, you do not want to expose yourself to fragmentation concerns or unneeded contention with other application data sets.
I AM RECEIVING THIS ERROR, BUT NONE OF THE ABOVE REASONS APPLY

Be prepared to still take recovery actions as listed.  To investigate further, Defect support will require the following information:
  1. LISTCAT ENT(catname) CAT(catname) ALL                                 
  2. joblog showing extend error                                           
  3. ISPF 3.4 "VTOC Summary Information" display                           
  4. IEHLIST LISTVTOC FORMAT                                               
  5. DSS PRINT of SYS1.VVDS.Vcatvol
//DSSPRINT EXEC PGM=ADRDSSU,REGION=0M                                    
//SYSPRINT DD SYSOUT=*                                                   
//SYSUDUMP DD SYSOUT=*                                                   
//DASD  DD UNIT=3390,DISP=SHR,VOL=SER=volser                             
//SYSIN    DD    *                                                       
   PRINT DATASET('SYS1.VVDS.Vvolser') INDD(DASD)

//LISTVTOC EXEC  PGM=IEHLIST                                             
//SYSPRINT DD SYSOUT=*                                                   
//SYSUT1    DD  UNIT=3390,VOL=SER=volser,DISP=SHR                        
//SYSIN     DD  *                                                        
  LISTVTOC FORMAT,VOL=3390=volser
 
                              
                                                                
                                                                                   

Document Location

Worldwide

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG90","label":"z\/OS"},"ARM Category":[{"code":"a8m0z0000000AATAA2","label":"DFSMS->Catalog->Error Codes & Abends"}],"ARM Case Number":"TS003819749","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Version(s)","Line of Business":{"code":"LOB56","label":"Z HW"}}]

Product Synonym

Catalog; 5695DF105; ICF Catalog; zCatalog

Document Information

Modified date:
03 September 2021

UID

ibm16232702