The CXXMAINT DDPROD option updates the Directory (CXX) with CA Datacom® Datadictionary™ definitions. This option reads the input file as created by CA Datacom® Datadictionary™ and updates the Directory to reflect any changes, additions, or deletions.
CA Datacom® Datadictionary™ also provides a means of cataloging CA Datacom® Datadictionary™ definitions directly to the CA Datacom®/DB Directory.
The following topics are discussed on this page:
Use the DDPROD option to update the Directory when adding or changing definitions in CA Datacom® Datadictionary™ which must be reflected in the Directory. Perform the tasks in the following order:
You can also use the DDPROD option to create a new database with a different database identifier from an existing production database definition. This option is useful to create a replica of a database for testing purposes.
You can change an existing database definition as long as no task is actively processing the database. Use the ACCESS function (for details see ACCESS (Restricting Opens or Maintenance)) to prevent opens to a database that you want to change.
As CA Datacom®/DB processes each table definition, the current Directory content is compared to the CA Datacom® Datadictionary™ definitions.
If any tables in the database being updated are not loaded, they are deleted from the Directory at the start of the process. The data set name is lost and to restore it, you must initialize the area or use the CXXMAINT OPTION=ALTER,DSN= utility function. A report of the Directory taken at this time does not provide area space information. The next LOAD of the area restores the information.
The action taken by CA Datacom®/DB depends on the situation encountered, as follows:
New Area, New Table
If an area is new and no match exists in the Directory, CA Datacom®/DB adds the area with no initialization information. CA Datacom®/DB adds the new table with no initialization information, and sets it as not loaded.
Existing Area, New Table
If the table is new, CA Datacom®/DB adds it. If the area containing the table exists and is loaded, CA Datacom®/DB sets the new table as loaded and having zero records.
If you are adding a table to an existing area, CA Datacom®/DB updates the area with the new CA Datacom® Datadictionary™ entity-occurrence information, data set space option, and slack information to the new values. If the block size differs, CA Datacom®/DB saves the new block size in the area definition as the next block size until the next INIT of the data area.
Existing Area, Existing Table
If the table currently exists, CA Datacom®/DB compares the Directory and CA Datacom® Datadictionary™ versions. If a critical change has occurred, CA Datacom®/DB leaves the current table in *HISTORY* status and adds the new table as not loaded.
Special codes on the Impact Report indicate critical changes and the reason. The codes and reasons associated with an Impact Report are as shown in the following list.
Impact Report Codes and Reasons
When you have to reload the data area to make the new table definition usable, you can run a SEQ=NATIVE BACKUP or EXTRACT function which use the *HISTORY* definition to access the old data, change its format if necessary, and reload the area. When the reload completes, CA Datacom®/DB marks the new table definition loaded.
If you are moving a table from one area to another, back up the area or extract the table before cataloging or using DDPROD to update the definition.
Do not use the CXXMAINT DDPROD option for SQL accessible tables or on a database containing SQL accessible tables. Instead, use the CA Datacom® Datadictionary™ CATALOG transaction.
The MUF must be active when you execute this command. Execute DBUTLTY with the command:
►►─ CXXMAINT OPTION=DDPROD,DDNAME=d ─┬──────────────┬─────────────────────────►◄
└─ ,NEWDBID=n ─┘
7-byte names that end with what could be a database ID from 1000 through 9999.
The DDNAME= value is verified for acceptability to protect you from unintentionally causing data corruption. The DDNAME check is the default but optional. You can prevent the DDNAME check by using a DBSIDPR parameter (DBUTLTY_EDIT_DATA_SET=) for individual MUF environments. However, we recommend that you allow the DDNAME check.
The data corruption risk involves not the DDNAME itself but the content of the data set. For example, suppose that you used the CXX DDNAME as the output of a backup. You then copied the CXX DD statement and changed the DDNAME of the copy to be acceptable, avoiding the DDNAME= error. The backup would, however, then overlay the CXX data set, which is not the intent of a backup.
If you specify an unacceptable name for DDNAME=, message DB10059E is generated.
Specifies a different database ID to be assigned to the definition. Use this keyword to create a set of new definitions quickly that are identical to a production base. Do not use this keyword when performing a normal update.
The following shows the command to update the CA Datacom®/DB Directory, using the CA Datacom® Datadictionary™ data in DDCFBLD.
//jobname See the previous note.
// EXEC PGM=DBUTLTY,REGION=2M
//STEPLIB See the previous note.
//CXX DD DSN=cxx.data.set,DISP=SHR Directory data set
//DDCFBLD DD DSN=dd.output,DISP=OLD Input from <DDD>
//SYSIN DD * Command Input
Following is a sample report page. For an example report header, see Sample Report Headers.
This page of the report shows the following:
BASE AREA TABLE ID DISPOSITION
390 ALI ALI 003 LOADED
ALT ALT 001 OLD
ALT 001 NOT LOADED (11)
APL APL 002 LOADED
LLN LLN 004 LOADED
MST MST 005 INDEX NOT LOADED
SCR SCR 006 LOADED
This page of the report shows a DBUTLTY impact report that gives the disposition of each table in the database as one of the following: