Limited support BMC provides limited support for this version of the product. As a result, BMC no longer accepts comments in this space. If you encounter problems with the product version or the space, contact BMC Support.BMC recommends upgrading to the latest version of the product. To see documentation for that version, see ALTER and BMC AMI Change Manager for Db2 13.1.

Change Manager objects


BMC AMI Change Manager for Db2

 uses the following objects to perform its tasks.

This section describes each of the objects in detail.

  • Work IDs
  • Worklists
  • Unload data sets
  • Baselines
  • Profiles
  • CDL files
  • DDL files
  • Internal tables
  • Task IDs
  • Scripts
  • Applications
  • DML
  • CM/PILOT worklists

The work ID and unload data set objects are the same objects as in ALTER. For a description of these objects, see ALTER objects.

Change Manager worklists

When Change Manager is used in the Database Administration or BMC AMI Database Administration for Db2 solution, the worklist can also contain keywords that control the sequencing of parallel processes.

For information about the BMC Database Administration for DB2 and BMC AMI Database Administration, see Solution-integration.

Baselines

A baseline contains a set of data structures and their associated authorizations, taken at a specific point in time, from the Db2 catalog, a DDL file, or a worklist.

Change Manager uses structure-only and full-recovery baselines:

  • A structure-only baseline contains only data structures.
  • A full-recovery baseline contains data structures and data.

The types of input to a baseline are as follows:

  • Db2 catalog

    A catalog baseline takes its input from a subset of the Db2 catalog. See Baseline profiles.

  • DDL file

    A DDL baseline takes its input from a file containing SQL DDL statements.

  • Worklist file

    A worklist baseline takes its input from a worklist that Change Manager or another BMC product produces. A worklist baseline is identical to a DDL baseline except for the input source file type. See Baseline profiles

Profiles

Profiles are a collection of scope rules, change rules, and locations that enable you to define and control the Analysis, Compare, and Baseline processes.

You use profiles to:

  • Select a set of objects
  • Customize changes to objects that are migrated to other subsystems
  • Create baselines of application data structures

Profiles enable you to automate changes instead of selecting objects individually for migration or making individual changes to object structure definitions. You can create, copy, edit, and reuse profiles.

Two types of profiles are used in Change Manager: baseline profiles and migrate profiles.

Baseline profiles

You use baseline profiles to create, name, and maintain baselines of application data structures.

You can automatically manage the baselines that you want to keep and those that you want to delete by specifying delete and retain values in the baseline profile. The two types of baseline profiles are catalog and DDL (or worklist) profiles.

  • Catalog baseline profiles

    The profile for a catalog baseline must contain scope rules that select the Db2 objects to include in the baseline or comparison. The baseline profile can explicitly specify the scope rules or can reference the scope rules in an outbound migrate profile.

    Scope rules are used only when a process is being performed on the Db2 catalog. The scope rules serve to create a subset of the Db2 catalog.

  • DDL or worklist baseline profiles

    When defining a DDL baseline profile, you define only header information. The scope is implicitly defined by the set of objects in the DDL or worklist.

Migrate profiles

You use migrate profiles to select a set of objects and to customize changes to objects that are migrated to different locations.

The two kinds of migrate profiles are inbound and outbound.

  • Inbound Migrate Profiles

    The Import component uses inbound migrate profiles to make input from another system compatible with the receiving subsystem’s version of the application. Inbound migrate profiles contain only change rules that modify imported data structure definitions.

    The change rules are applied as the CDL file or DDL file is imported. For example, if a change rule specifies changing the database name DEMO* to ACM*, the DDL statement CREATE DATABASE DEMOHRS is read and the CD table entries are generated with a CREATE DATABASE ACMHRS. The profile’s change rules are applied to the imported data structure definitions before CD table entries are created.

    You cannot specify scope rules or locations with an inbound migrate profile. The file being imported identifies the scope.

  • Outbound Migrate Profiles

    You use outbound migrate profiles to generate worklists or CDL files. The outbound migrate profile can contain the following items:

    • A scope for specifying the Db2 objects to include in the operation
    • Locations for defining multiple clones of an application
    • Change rules for defining attribute changes to be automatically applied to objects in each clone

    You can group locations if they reside in the same Db2 subsystem.

    When an outbound migrate profile is used as input to Analysis, a worklist is generated for each group specified. One CDL output file is generated for each group when an outbound migrate profile that specifies locations is used as an input to the comparison.

    The Compare process can also use the scope rules of an outbound migrate profile to select a subset of objects from the Db2 catalog to use in a comparison with a DDL file or worklist.

GUID-47E5A770-A760-442A-9F5A-06872981813D-low.png

For more information, view the Quick Course CHANGE MANAGER for DB2 - Creating Migrate Profiles.

Scope rules

When you define scope rules for a profile, you are specifying which objects to fetch from the catalog.

You can reference scope rules when you perform a comparison, create a baseline, or analyze a work ID.

In a catalog baseline profile, scope rules specify the Db2 objects to include in the baseline. The scope rules of an outbound migrate profile can specify the objects to migrate or the Db2 objects to include in a comparison. Scope rules can include Db2 objects in the final set of objects to be processed or can exclude them from the final set.

Scope rules can select a specific object or select groups of objects (through the use of wildcard characters) as the set or sets of objects on which to operate. Scope rules can also determine which dependent objects to include and to exclude. For example, a scope rule could include database ABCDEF and its dependent table spaces, tables, indexes, foreign keys, and views, but exclude its dependent synonyms, aliases, or data.

You can define scope rules for both migrate profiles and catalog baseline profiles. You can follow the same procedure to create a set of scope rules for each type of profile. You can also use the same set of scope rules for different profiles. For example, when creating a catalog baseline profile, you can reference the scope rules of a migrate profile. Likewise, a migrate profile can reference the scope rules of a catalog baseline profile. This feature enables you to use the same list to select the same objects for either migration or a baseline.

The Compare component uses the scope rules of a catalog baseline profile when it compares a catalog baseline to the Db2 catalog. The Compare component finds the baseline profile by using the established baseline name, and then uses the scope rules of the catalog baseline profile to select the objects to compare. Compare can also use the scope rules of a specified profile when it compares a Db2 catalog to a DDL file or to a worklist.

Change rules

Change rules modify the attributes of existing Db2 object structure definitions.

The change rules compare the object type and attributes to those in the migrated data structures. The change rules are applied when the attributes and the names match. For ALTER, you can define change rules within a migrate-type work ID. For Change Manager, you can define change rules within a migrate-type work ID or a migrate profile.

When you define change rules within a migrate profile, the rules are processed for each object that is defined in the scope of the profile. You can streamline and automate changes to sets of object structures by defining change rules for migrate profiles. Because migrate profiles are used in different types of migration processes, special consideration of how change rules work can significantly contribute to the efficient performance of these processes.

Change rules allow you to easily specify and repeat common changes. For example, in many Db2 installations, the owner of a table changes when the table is moved from a test system into production. A migrate profile can perform the changes that are necessary to migrate the structures from the test system into production. This profile can include a change rule that changes all of the tables with owners that match TEST to PROD.

Change rules can perform the following tasks:

  • Change the names of objects
  • Change the attributes of a specified object or group of objects
  • Include specific volumes in a storage group, or exclude volumes from a storage group
  • Exclude one or more columns from a table
  • Specify that table spaces and indexes that have a STOGROUP attribute be defined to use VCAT on the receiving database
  • (Compare only) Suppress changes to altered objects

Locations for outbound migrate profiles

Locations, which are defined only in outbound migrate profiles, enable you to create or maintain multiple clones of an application schema.

When an outbound migrate profile contains locations, a worklist or CDL is generated for each location or Db2 subsystem that is specified.

For example, if your installation supports systems in New York, Dallas, and Atlanta, you can create a profile with a location for each system. Each location can have change rules that tailor object names and attributes for that system. Each location can have its own change rules, or can reference the change rules of another location within the profile.

You can also group several locations under a single Group ID to generate just one worklist or one CDL file. Using the Group ID enables you to execute all of the work for a single subsystem in one process. This action is useful when you are migrating or updating several clones of a structure that reside on the same subsystem.

For example, if a development facility has 25 developers, each of whom have their own copy of the application schema, you could use a Group ID to migrate all 25 copies of the schema within a single worklist.

CDL files

CDL is a BMC proprietary language that you use to specify changes to Db2 data structures. You can use CDL files to transmit data structure changes between subsystems or to provide a record of changes to data structures.

CDL files specify the changes that are required to transform a primary set of data structures to a secondary set of data structures. You use CDL files in the change, import, and recovery processes.

Change Manager DDL files

Change Manager can generate executable SQL DDL statements (in SPUFI format) when generating a baseline report.

DDL files are used as input by the Import, Baseline, and Compare components.

Change Manager internal tables

Change Manager uses several types of internal tables to perform tasks.

The tables that Change Manager uses are as follows:

  • BL tables, which store information about baselines (data for full-recovery baselines is stored in external data sets)
  • CD tables, which store change and migration specifications for each work ID
  • CM tables, which store work ID, change rule, and sync data
  • CP tables, which store information about CM/PILOT task IDs, applications, scripts, and DML

Access to most of the internal tables is controlled by the granting of EXECUTE authority on the appropriate plans.

Task IDs

A task ID is a unit of work in the CM/PILOT component.

Each task ID has a unique name and contains information that you provide through the panel to perform a Change Manager process. The information that you provide is based on the script the you select for the task ID. All work in CM/PILOT is accomplished by processing task IDs.

Scripts

The panels that the CM/PILOT component displays are based on predefined steps called scripts.

Each script contains ordered steps that prompt you for the information that is required to perform a change management task. Change Manager provides you with several scripts; you can also create your own script, or copy, change, and rename any of the scripts that are supplied by Change Manager.

Applications

In the CM/PILOT component, you can associate a group of Change Manager profiles that are used repeatedly for the change management tasks of a specific Db2 application.

This association is called an application.

DML

In the CM/PILOT component, you can use DML statements to update, delete, and migrate data structures.

You can change or migrate multiple objects in a single DML statement. The panels for two of the CM/PILOT scripts help you create the DML statements.

CM/PILOT worklists

A CM/PILOT worklist is a data set that contains the ordered commands, keywords, and parameters that are needed to process a task ID.

The format of the CM/PILOT worklist is similar to an Analysis worklist. The JCL that processes the CM/PILOT worklist contains the names of the output data sets that an Analysis worklist uses and the associated Execution JCL. When a CM/PILOT worklist is successfully processed, the result is the creation of an Analysis worklist and the Execution JCL to process the worklist.


 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*