How to manage space in CA 11 database files
search cancel

How to manage space in CA 11 database files


Article ID: 43723


Updated On:


Datacom DATACOM - AD


This article will explain how the Datacom database files are allocated and used, and how they can be monitored and maintained. There are references to several jobs throughout this document; these can be found in the PDS created from the attached file, which has been tersed. You can upload the Space601_PDS_Tersed file from your PC to the mainframe as a binary file with an LRECL of 1024, and then unpack it. Here is JCL to recreate the PDS:

// SET TERSFL=<<Your downloaded tersed file
// SET OUTPDS=<<A New PDS filename for the utilities
//X01      DD  DSN=&OUTPDS,
//             DISP=(MOD,DELETE,DELETE),UNIT=3390,SPACE=(TRK,1)
//* - - - - - -C- - - - - - - - - - - - - - - - - - - - - - - - - - -7-+
//             UNIT=3390,STORCLAS=TSO,DSORG=PO,SPACE=(CYL,(1,1,5),RLSE)





Release: 15.1


These are the members from the above PDS referenced in this article:

CXRPFULL - Full CXX report of your database

SPACERPT - DBSQLPR report processed with REXX to produce composite report

CXRPTYPA - Directory Space Utilization CXX report (Type=A) for your database

DEFRG601 - Database Index Defragmentation utility

RETXA601 - RETIX utility to run on existing file as is

CLOSE601 - DBUTLTY job to CLOSE and turn of ACCESS to the database

RETXB601 - Allocation, initialization and rebuild of new database 11 Index file

ALLOC601 - Allocation, initialization of all database areas

The application database files themselves are standard PS files, subject to the same rules as any other PS file (16 extents per volume, for example). This means that a file that is nearing 100 percent full is really only nearing 100 percent full for the extents allocated, so it can most likely be extended rather than requiring a reallocation. To accomplish this, all database areas should have two key parts to their creation:

  1. The allocation of the file with both primary and secondary space specified; and
  2. The database definition (in Datadictionary and the CXX) with Dynamic Extend enabled.

How can you tell the file allocation for your database files? Since Datacom gets the volume information from the catalog when it dynamically opens each database area, we do not store that information in our system.

However, you have two options:

  1. You can run a full CXX report and use that information to get the file allocations from the system catalog; or
  2. You can run a query with SQL to extract the information from the Datacom System Tables, then use a REXX program to look up the information directly.

To run the CXX report, please see member CXRPFULL in the aforementioned PDS.

Note that you can choose a single DBID per function, or you can remove the "DBID=601" parameter to report on the entire system. In the output of the CXX report, you should look for "DATA SET NAME" to get the filename, and on the right side of that same line, you should see the area and database. For example, if you have:

DATA SET NAME - QDBA00D.C131.DSN601               DATA  DTF/DDNAME - DSN601

Then for Area DSN in database 601, the filename is QDBA00D.C141.DSN601. You would then take this file and search in your catalog to display the attributes (ISPF 3.2 or 3.4) and to see how many extents the file has.

To report the data from the Datacom System Tables, you would run program DBSQLPR (if you are licensed for the Datacom SQL Option), with the SPACERPT job below. This job will run DBSQLPR to extract the database information, and then pass it into the REXX program which will look up the catalog details and provide a 2-part report of the results. Note that the report output is 150 bytes long.

To run this report, please see member SPACERPT in the aforementioned PDS.

This will give you a 2-part report like this:

Part 1:

DBDSI Output:
 DBID ARA  Used Blks   Tot Blks  Pct  Tot Tracks Extnd Extend Amt  Area File Name                               Volser  Seq#
----- --- ---------- ---------- ----- ----------  ---  ----------  -------------------------------------------- ------ -----
    1 DEM         12         99  12.1          3  NO               DATACOM.MUF001.BD1400A.DBDEM                 DCMSP2     1
    1 IXX         15         36  41.6          3  NO               DATACOM.MUF001.BD1400A.DBIXX                 DCMSP4     1
    1 PAY         13         66  19.6          2  NO               DATACOM.MUF001.BD1400A.DBPAY                 DCMSP2     1
    1 PMF         17     238656   0.0       7232  NO               DATACOM.MUF001.BD1400A.DBPMF                 DCMSP2     1
    1 PMF         17     238656   0.0       7232  NO               DATACOM.MUF001.BD1400A.DBPMF                 DCMSP5     2
    1 PMF         17     238656   0.0       7232  NO               DATACOM.MUF001.BD1400A.DBPMF                 DCMSP6     3
    2 DD1       2598      11700  22.2        975  YES      10 TRK  DATACOM.MUF001.BD1400A.DD1002                DCMSP5     1
    2 IXX       1901       3600  52.8        300  YES      20 TRK  DATACOM.MUF001.BD1400A.IXX002                DCMSP8     1

Part 2:

File Name                                    RC Seq Volume  Ext AllocTyp  Primary,Seconds    Alloc    Used  Seq Type
-------------------------------------------- -- --- ------- --- -------- (-------,-------) ------- -------  --------
DATACOM.MUF001.BD1400A.DBDEM                 00   1 DCMSP2   1  TRACK    (      3,      0)       3       3  BASIC
DATACOM.MUF001.BD1400A.DBIXX                 00   1 DCMSP4   1  TRACK    (      3,      0)       3       3  BASIC
DATACOM.MUF001.BD1400A.DBPAY                 00   1 DCMSP2   1  TRACK    (      2,      0)       2       2  BASIC
DATACOM.MUF001.BD1400A.DBPMF                 00   1 DCMSP2   1  TRACK    (      2,      1)       2       2  BASIC
DATACOM.MUF001.BD1400A.DBPMF                 00   2 DCMSP5   1  TRACK    (   2700,   2700)    2700    2700  BASIC
DATACOM.MUF001.BD1400A.DBPMF                 00   3 DCMSP6   3  TRACK    (   2700,   2700)    4530    4530  BASIC
>>> Totals for 3 volumes:                           >>3>>>   5                                        7232
    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -
DATACOM.MUF001.BD1400A.DD1002                00   1 DCMSP5   1  CYLINDER (     65,      5)      65      65  BASIC
DATACOM.MUF001.BD1400A.IXX002                00   1 DCMSP8   1  CYLINDER (     20,      2)      20      20  BASIC

In this report, you can see if the database area is defined to dynamically extend (column Extnd), and if so, what the extend amount is as shown in the CXX. This is the same as looking in the full CXX report for "DYNAMIC EXTEND" and "DYN.EXT.TRACKS" for these values.

If the CXX/SQL report contains an extend amount as in the example above - showing 10 tracks for both the DB002 IXX and DD1 areas - this value will be used for each extent. If this value is blank or zero, each extend will take the value of the file's secondary allocation if it exists in the catalog.

At this point, you have seen how to determine the physical file attributes (space allocation and extents), and how to determine if the database area can be dynamically extended. How can you determine if you have a problem and need to extend the database area?

For Datacom/AD, the database areas should already be defined with DYNAMIC EXTEND set to YES. This means that as records are added to the database, if an area will reach 100% full, the MUF will hold and stop adding records for a moment, and it will add an extent to the file, initialize it and update the CXX (internal database catalog). It will then resume adding records to the file without issue. Once you have reached the limit of file extents and/or volumes, any attempt to extend the file further will result in an x37 abend; consequently, it is good practice to monitor the number of extents on a regular basis.

The space utilization is best monitored through the use of the Directory Space Utilization CXX report. This will produce a 1-line summary of each area, showing the current and maximum PCT FULL values.

To run this report, please see member CXRPTYPA in the aforementioned PDS.

As before, you can restrict each function to a single DBID, or you can remove the DBID= parameter to report on all databases. Be sure to include the COMM OPTION=STATS function before the REPORT function to ensure you have the most current data. This will produce a report like this (the two right-hand columns were removed here):

AREA DATA       TOTAL           TOTAL       TOTAL       USED    PERCENT
CXX               250           N/A         3,000         302    10    10
IXX  1575       1,650           N/A        19,800      15,506    78    78
 G01 1575       3,000             615      18,000           9     0     0
 G02 1575       6,000       1,032,845      12,000      11,098    92    96
 G03 1575      54,000       5,768,535     108,000     105,323    97    97
 G04 1575       3,000             936      18,000          19     0     0

In this report, you can see that area G02 in database 1575 is currently 92 percent full, and the highest it has been since the area was initialized was 96 percent.

Now, to maintain the database files, you have several possibilities. If the Index is getting full, you can allow it to dynamically extend if desired. However, we have seen that certain Datacom/AD products can benefit by clearing out empty blocks that may have pointed to records that are now deleted. To recover these empty blocks and reduce your index utilization, you can run the DBUTLTY DEFRAG function. This function will run while the MUF is up and running, and while the application is processing. There is a minimal potential for a performance impact, but it is highly unlikely and will not last long.

To run this DEFRAG job, please see member DEFRG601 in the aforementioned PDS.

In some cases, you may want or need to rebuild the index, without allocating the index file at a different size. For this process, you will need exclusive control of the database. Normally the application will be suspended or shut down to run this process - but the MUF will stay running.

To run this RETIX job "in-place," please see member RETXA601 in the aforementioned PDS.

If you have a need to reallocate the index because it is truly getting full, this also requires exclusive control of the database, meaning the application must be shut down or suspended. Note that there are two jobs here - This is necessary to avoid any problems with ENQues on the index (IXX) file. Run the first, and when it has CC of zero, then you can run the second to correct the problem.

To run this RETIX job and allocate a new index file, please see members CLOSE601 and RETXB601 in the aforementioned PDS.

The process to reallocate the file for a data area is similar. You will start by taking a backup of the database, and then you can allocate a new data area and reload the data into it. This job can be used to reallocate a single area, or all areas in the database.

To run this BACKUP and LOAD job, please see members CLOSE601 and ALLOC601 in the aforementioned PDS.

Hopefully, this information will help more easily manage your Datacom/AD databases, and reduce or prevent outages due to problems with file space.


Additional Information

More information about the various DBUTLTY functions referenced here can be found in the Datacom documentation in section DBUTLTY Reference

As always, please contact Broadcom support for Datacom if you have further questions.

Attachments get_app