Overview of Change Manager

BMC AMI Change Manager for Db2 enables the DBA to effectively deal with the demands of a constantly changing environment involving multiple Db2 subsystems. Like ALTER, Change Manager uses an ISPF interface.

Change Manager includes all of the features in ALTER and provides the following additional capabilities:

  • Migrates data structure changes across multiple databases and subsystems

  • Determines changes to data structures and migrates those changes to one or more copies of the data structures

  • Captures and records structure definitions and data within a Db2 subsystem at a point in time (to establish a full-recovery baseline)

  • Recovers structures and data to a point in time defined by a full-recovery baseline within a Db2 subsystem

  • Compares two versions of structure definitions to:

    • Determine the changes necessary to upgrade one version to another

    • Selectively apply changes to copies of the data structures while preserving the uniqueness of each copy

  • Uses data modeling tool outputs to determine the changes to existing Db2 application structures

  • Reduces the volume of information that is needed to communicate changes by using a BMC language called Change Definition Language (CDL) to transmit the change information

  • Feeds changes that are made on a remote system back to the development system

  • Defines and stores reusable rules for making changes

  • Uses SQL-like statements to update, delete, and migrate data structures

Change Manager provides full management support for the same Db2 data structures as ALTER does.

Data structure change migration

Change migration, which means to migrate only data structure changes (instead of entire structures) to another copy of the structure on the same Db2 subsystem or on a different Db2 subsystem, enables you to update structures that have already been migrated to another copy.

However, you must also be able to retain any structure modifications that were made locally after the structures were migrated. Db2 users often make local modifications—or variations from the control definition of the application—to meet the following needs:

  • Performance and usage tuning

    Local tuning is a complex process that is based on the specific system that is involved and the performance and use of the application in that environment. Because separate sites often have different amounts of data and different transaction loads, as well as different CPU and Db2 environments, local tuning of application structures is common.

  • Security

    Authorization requirements are associated with object ownership and, in some cases, with object names. As a result, the authorizations for one Db2 subsystem can vary significantly from the authorizations of another subsystem running the same application. In this situation, each subsystem requires local modifications to the application.

  • Additional uses of data

    Often, production systems in a Db2 environment need to use data that is beyond the fixed scope of an application. For example, the data in a payroll application might be needed for reports that the finance department develops. Db2 enables users to locally generate additional data structures (such as indexes, synonyms, views, aliases, and authorizations) to meet these needs.

Because local modification of applications is so common in Db2, users need an application management strategy that enables them to manage basic elements of the application globally, without compromising the elements that vary locally.

Change Manager satisfies the requirement of migrating global changes while retaining local modifications by:

  • Determining the changes made to the control version of the application

  • Applying only those changes to other versions while preserving all local modifications

Change Manager can also determine the accuracy of the proposed changes before applying them. Because changes are allowed at the lowest level of an object’s definition, Change Manager preserves and converts data as necessary to accommodate the requested changes.

Additionally, Change Manager propagates changes to all dependent structures. For example, when you change a column name, Change Manager propagates the change to any index and foreign key definitions that use the column, even though the index and foreign key definitions might be unknown to the sending Db2 subsystem.


BMC does not recommend using Change Manager or the CM/PILOT component of Change Manager to modify the Db2 catalog, directory, and workfile objects.

Data structure recovery

Changes to data structures might not produce the effect that you intended.

For example, a change might significantly increase an application’s response time. In this case, you might need to restore the previous data structures. While Db2 has features for logging, backup, and recovery of data, it has no similar features for data structures. If you make an unwanted structure change, or if your changes fail or are unusable, you must fall back to the previous definition. To do so, you must have saved the structure definitions and data of the previous version.

Change Manager enables you to capture a set of data structures from the Db2 catalog or DDL file and store the set in a baseline. A baseline can contain only data structures or data structures with their associated data.

Establishing baselines and recovering to them is called data structure recovery. You can reload the data that is stored in a full-recovery baseline after the structures have been recovered. You can also reload the data that exists in those structures at the time of their recovery. In addition, Change Manager can convert current data to match the restored data structures.

Change recording and controlling

Managing change also requires that you know what changes have been made to an application’s data structures during different periods of time.

Change Manager provides a comparison feature that can generate a file that shows the differences between two sets of data structures. Because the file is stored in a sequential data set or partitioned data set (PDS) member, you can view, edit, print, or store it.

Change feedback

Data structure changes might not flow in order from the development system, through testing, and into production.

Because changes to the basic application definition can occur at any point in the cycle, you must be able to transmit changes back to the development system or to the control node. Transmitting changes from a remote system to the development system (or to the control node) is called change feedback.

To feed back changes, Change Manager enables you to:

  • Identify the changes made

  • Apply the changes at the development or control system

You do not need to feed back all of the changes to the development system. You should feed back only those changes that are part of the globally managed basic definition of the application.

Data modeling tools

In many installations, the data structure design of the application is not controlled in a Db2 subsystem but in a data modeling tool (or Computer-Aided Software Engineering, or CASE, tool), data dictionary system, or other structure design repository.

In this guide, the term data modeling tool refers generically to any external design tool.

Most data modeling tools generate an application’s DDL. Changing an application’s data structures generates new DDL, which you can use to create the data structures in the Db2 catalog. Although data modeling tools can improve the productivity of Db2 developers, the use of these tools creates the following problems:

  • If you make an emergency change in a production system, including that change in the data modeling design is difficult and usually requires a manual entry. You can use host-based Db2 tools to make emergency changes (or to define local structure elements not supported by a data modeling tool), but the changed structures will no longer be synchronized with the data modeling design.

  • Often, communication between a data modeling tool and Db2 is one way. You can design structures on the data modeling tool and transmit the structures to Db2, but updating the data modeling design after making changes at the Db2 node is difficult.

  • Most data modeling tools cannot selectively modify data structures. Because these tools can transmit only a complete application definition, they might be useful only for the initial design of an application. Maintenance and upgrades are then performed at the Db2 level.

  • Due to their ease of use and built-in design intelligence, data modeling tools are popular for managing global application data structure definitions. However, the external Db2 specifications that a data modeling tool produces might be incomplete or might fail to reflect local elements of the design.

You can address these problems by using Change Manager to migrate changes between the data modeling definition of an application and the Db2 definition. Change Manager enables you to:

  • Establish control points for the application’s data structures and determine the changes that are made between those control points

  • Implement design changes in Db2 without losing either the application’s data or its local data structure modifications

  • Transmit changes from Db2 back to the data modeling tool after making global changes to the Db2 version of the application’s data structures

Was this page helpful? Yes No Submitting... Thank you