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
//*
//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)
//
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:
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:
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):
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 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.
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.