How to manage CA Datacom/AD database space (z/OS 2.1 and higher)

Document ID : KB000010053
Last Modified Date : 14/02/2018
Show Technical Document Details
Introduction:

This article will explain briefly how CA Datacom database files are allocated and used, and how they can be monitored and maintained. It will help you identify if a database area is getting dangerously full regardless of your application configuration. 

There are references to several jobs throughout this document to help you manage your database space; these can be found in the PDS created from the below file, which has been tersed.

Space_Mgmt_zos21_Tersed

You should upload the tersed file from your PC to the mainframe as a binary file, as FB, LRECL=1024, BLKSIZE=27648. Here is JCL you can use to recreate the PDS:

//*
// SET TERSFL=<<Your downloaded tersed file
// SET OUTPDS=<<A New PDS filename for the utilities
//*
//DELETE   EXEC PGM=IEFBR14
//X01      DD  DSN=&OUTPDS,
//             DISP=(MOD,DELETE,DELETE),UNIT=3390,SPACE=(TRK,1)
//* - - - - - -C- - - - - - - - - - - - - - - - - - - - - - - - - - -7-
//UNTERSE  EXEC PGM=AMATERSE,PARM=UNPACK
//SYSPRINT DD  SYSOUT=*
//SYSUT1   DD  DISP=SHR,DSN=&TERSFL
//SYSUT2   DD  DISP=(NEW,CATLG,DELETE),DSN=&OUTPDS,
//             UNIT=3390,STORCLAS=TSO,DSORG=PO,SPACE=(CYL,(1,1,5),RLSE)
//*

These are the members from the above PDS that are referenced in this writeup:

ALLOC161 - Job to reallocate CA Jobtrac (DB 161) areas 
ALLOC430 - Job to reallocate CA Scheduler (DB 430) areas 
ALLOC601 - Job to reallocate CA 11 (WA) (DB 601) areas 
CLOSE    - Job to turn off access and close a database in the MUF 
CXRPFULL - Job to run a full CXX report for a database 
CXRPTYPA - Job to run a CXX space report (Type=A) for a database 
DEFRAG   - Job to defragment the index for a database 
RETIXA   - Job to recreate the index for a database - in place 
RETIXB   - Job to recreate the index for a database with a new allocation 
SPACERPT - Job to produce a detailed space report of all CA Datacom databases

(Items in RED will affect the operation of the database, and applications should be stopped; items in BLUE are benign and can run at any time).

Environment:
This article applies to CA Datacom/AD version 14.0 and higher, running on z/OS 2.1 and higher.
Instructions:

Each application database file is a standard sequential (PS) file, subject to the same rules as any other PS file. As a BASIC type file, it is limited to 16 extents per volume, and no more than 65535 tracks on one volume. This file can be allocated on as many as 59 volumes if needed. If more than 65535 tracks are needed on a volume, allocating the file with DSNTYPE=LARGE will allow up to 16,777,215 tracks on a single volume. CA Datacom does not support Extended Format files, but using DSNTYPE=LARGE should meet most application needs. For more information about file allocations and limits, please see the IBM DFSMS Using Data Sets manual:

* For z/OS 2.2, DGT3D410 - http://publibfp.dhe.ibm.com/epubs/pdf/dgt3d410.pdf
* For z/OS 2.1, DGT3D400 - http://publibfp.dhe.ibm.com/epubs/pdf/dgt3d400.pdf

Using these standard PS file rules 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 CA Datacom gets the volume information from the catalog when it dynamically opens each database area, we do not store all of that information in our system, but some is held in the Directory area (called CXX).

Here, 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= 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.AEX                             DATA  DTF/DDNAME - AEX131 

this says that for Area AEX in database 131, the filename is QDBA00D.C131.AEX. 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 can run program DBSQLPR (if you are licensed for the CA Datacom SQL Option), with a job to extract the database information, and then pass it into a 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 job 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 the "DYNAMIC EXTEND" and "DYN.EXT.TRACKS" values.

If the CXX/SQL report contains an extend amount as in the example above - showing 10 and 20 tracks for the DB002 DD1 and IXX areas, respectively - this value will be used for each new extent. If this value is blank or zero, each new extent be sized based on the value of the file's secondary allocation if it exists in the catalog (as shown above, 5 cylinders and 2 cylinders, respectively).

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 CA 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 command to ensure you have the most current data. This will produce a report like this (the two right-hand columns were removed here):

DATACOM/AD                   DATA AREA SPACE UTILIZATION REPORT
AREA DATA       TOTAL           TOTAL       TOTAL       USED    PERCENT
NAME BASE      TRACKS         RECORDS      BLOCKS      BLOCKS  FULL   MAX

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

In this report, you can see that area G02 in database 3575 has reached 92 percent full, and this is the highest it has been (MAX) since the area was initialized.

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 CA Datacom/AD products can benefit by clearing out empty blocks that formerly pointed to records that are now deleted. To recover these empty blocks and reduce your index utilization, you can use the DBUTLTY DEFRAG function. This will run while the MUF is up and running and while the application is processing. There is a minimal possibility of a very brief delay to the application, but it is highly unlikely and will not last long (milliseconds, in most cases).

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

In some cases, you may want or need to rebuild the index, using its current allocation. 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 members CLOSE and RETIXA 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 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 CLOSE and RETIXB 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 CLOSE and ALLOCnnn in the aforementioned PDS (nnn = 161 for CA Jobtrac, 430 for CA Scheduler, 601 for CA Workload Automation Restart Option for z/OS Schedulers - called CA 11).

Hopefully, with this explanation and with the supplied jobs, you will be able to easily and effectively monitor and maintain your application databases.

Additional Information:

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

File Attachments:
TEC1807358.zip