CA Endevor/DB's archive and compress facility, NDVRARCO, allows the CCDB administrator to eliminate obsolete information from the CCDB, to optimize disk space, to transfer essential data onto tape or disk for future reference, and to maintain essential information in special Configuration Change Log entries within CCDB. The archive and compress facility accomplishes this by performing the following tasks:
If an updating program (such as IDD) runs a job which is abended or interrupted, that incomplete job is marked as "uncommitted" in the CCDB database. CA Endevor/DB ignores uncommitted CLEs for change control purposes, and disposes of them when the ARCHIVE/COMPRESS program is run.
The goal of compression is to eliminate "noise" records in the CCDB that add little value to the audit trail or change control process. During compression, contiguous strings of CLEs, which relate to the same user and CCID entity are summarized into a single compressed CLE with a net action code (depending on the sequence of activity). When the Change Log History for dictionaries, CCIDs, users or entities is displayed, compressed CLEs appear in their original time relative positions. In order to do compress processing, the user must enter the COMPRESS command and specify a compress age.
Archive processing enables the CCDB administrator to transfer data from the CCDB into a sequential file (tape or disk). Typically, these records contain obsolete change information, which is no longer needed on a regular basis, yet warrants being preserved for future reference. Such would be the case, for example, when a migration is completed and the associated change information is no longer needed in the online database for future migrations, regression detection, or audit trail purposes.
Archiving that information would free up space in the CCDB while maintaining a "pre-migration" copy of that change log information on tape for historical purposes. In order to invoke archive processing, the user must specify the ARCHIVE command and specify the name of the CCID, USER, or MANAGEMENT-GROUP to be archived.
This function allows the CCDB administrator to modify the dictionary name and/or system identifier information contained in Confirmation Change Log entries written to the CCDB during the promotion, or migration, process.
When Derived CCID processing is used, secondary commit groups are sometimes created to associate Change Log Entries (CLEs) to CCIDs. The ARCHIVE/COMPRESS program converts them to ordinary commits.
Note: Because secondary commit records contain a dbkey as data, the ARCHIVE/COMPRESS program must be run prior to running any CA IDMS utility (such as UNLOAD/RELOAD) which will change dbkeys for existing CCDB NDVRCOMT records. The ARCHIVE/COMPRESS program will eliminate the stored dbkey values.
Installations commonly apply both compression and archive to the same CCDB, using these facilities for two basic purposes:
The use of CA Endevor/DB to control the promotion or migration process depends completely on the contents of the CCDB. The use of NDVRARCO's ARCHIVE processing removes Change Log records from the CCDB; the use of NDVRARCO's ALTER CONFIRMATION processing modifies the dictionary identification information contained in Confirmation Change Log records in the CCDB.
There are three major guidelines to be followed when using NDVRARCO's ARCHIVE processing.
If you intend to migrate dictionary entities to more than one target, you should never use NDVRARCO to archive the source dictionary development change history until the migration is complete to all targets. Do not archive a CCID used to trigger the selection of entities until it has been received by all target systems.
If you make changes to dictionary entities at two or more source dictionaries, you should never use NDVRARCO to archive change history until all affected dictionaries are synchronized. For example, let's say that development is done at dictionary A, QA at dictionary B, and production at dictionary C. If a migration from dictionary A to dictionary B is followed by a QA-related change at B, then the history of change at B cannot be archived until migrated to, or reproduced at, both A and C. Use the Post Migration Activity Report (NDVRPT15) to identify QA and production fixes.
If you make changes to vendor-supplied dictionary entities, you should never use NDVRARCO to archive the history of those changes. The audit trail of these changes will always be needed to upgrade to new maintenance levels and releases of the vendor product. Regular and exclusive use of compression in these cases will keep the growth of the CCDB at moderate and predictable levels.
NDVRARCO's ALTER CONFIRMATION processing requires some thought before its use. Since selection of entities for promotion is based on "the last time the entity was promoted to the target dictionary" and the target dictionary is identified by the Dictionary Name and System Identifier in the Confirmation Change Log records in the CCDB, accurate dictionary identification information is crucial. If a "hooked," or monitored, dictionary is moved from one system to another, or the system it resides in is renamed, or if the segment name of the dictionary is changed (causing a change in the Database Name Table DBName entry for the monitored dictionary), this information needs to be updated in the Confirmation Change Log entities in each applicable CCDB. The following guidelines should be followed:
If the dictionary name and/or system identifier of a source dictionary is changed, after updating the source CCDB's Dictionary Descriptor to reflect the change, ALTER CONFIRMATION commands should run against each target CCDB into which entities from the source dictionary have been promoted to reflect the new source dictionary identification information. This information is contained in "Migrate In" (Action Code "V") Confirmation Change Log records in the target CCDB.
If the dictionary name and/or system identifier of a target dictionary is changed, after updating the target CCDB's Dictionary Descriptor to reflect the change, ALTER CONFIRMATION commands should be run against each source CCDB from which entities have been promoted to reflect the new target dictionary identification information. This information is contained in "Migrate Out" (Action Code "C") Confirmation Change Log records in the source CCDB..eul
|
Copyright © 2013 CA.
All rights reserved.
|
|