Tool Mentor: CICS CM – Perform Deployment
TM137 – How to use IBM CICS Configuration Manager to deploy CICS resource definitions
Tool: IBM CICS Configuration Manager
Relationships
Main Description

Context

Tool mentors explain how a tool can perform tasks, which are part of ITUP processes and activities. The tasks are listed as Related Elements in the Relationships section.

You can see the details of how processes and activities are supported by this tool mentor, by clicking the links next to the icons:

Details

To manage the distribution of CICS resource definitions, use IBM® CICS Configuration Manager® for z/OS (CICS CM). CICS CM allows you to build a package of related CICS resource definitions that can be migrated across complex CICS topologies.

A change package identifies a set of resource definitions that you want to process together. You can process a change package to:

  • Migrate resource definitions between CICS configurations stored in:
    • CSD files
    • CICSPlex SM contexts
    • Export files – used to transfer resource definitions to remote sites
  • Install resource definitions in active CICS regions
  • Back out (undo) changes after migrating

To migrate a set of resource definitions between CICS configurations, follow these steps:

CICS configurations

Typically, before migrating resource definitions from one environment to another, you edit the resource definitions in the first environment. For example, before migrating resource definitions from a development system to a test system, you typically edit the resource definitions in the development system. Before proceeding, you confirm that the development system works after the edit.

You package resource definitions by adding them to a change package. This allows you to migrate a set of resource definitions together. You can package any number of resource definitions, such as programs and files.

When you are satisfied with the resource definitions and wish to migrate them to another CICS environment, you mark the change package as ready for a particular migration scheme. This indicates that you want no further edits to the change package prior to migration.

Only change packages that are ready can be approved. If a change package requires approval, then it must be fully approved before it can be migrated. When you approve (or disapprove) a change package, you specify the approver role that you are representing (for example, “I am approving this change package as a project manager”).

Suppose that a change package has been marked as ready, but you want to postpone its approval or migration. To do this, you mark the change package as unready, preventing it from being approved or migrated. Later, when you want to approve or migrate the change package, you mark it as ready again.

When you issue the command to migrate the change package, you instruct CICS Configuration Manager to:

  • Confirm that the change package is still ready (has not changed since you marked it as ready, and has not been marked as unready)
  • If approval is required: confirms that the change package is fully approved
  • Read the candidate resource definitions from the source CICS configurations, and transforms them according to the rules specified by the migration scheme
  • Write the transformed candidates to the target CICS configurations, and writes before and after images of these migrated resource definitions to the journal (so that you can back out the migration later)
  • Add the migrated resource definitions to the change package. This allows you to reuse the change package to progressively migrate resource definitions between environments.

If a migration fails for any of the resource definitions in a change package, then CICS Configuration Manager stops the migration, and undoes changes to resource definitions that have already been migrated. Similarly, if the CICS region running the CICS Configuration Manager server abends during a migration, then when you restart the CICS region, CICS Configuration Manager undoes changes performed by the partial migration. This automated process is known as a roll out, and ensures that the resource definitions in a change package are migrated together – either all or none are migrated.

If a change package migration succeeds, you can issue a command to back out (undo) the migration.

A roll out or back out of a change package spans multiple CICS units of work and sync points, and will be performed and continued across a CICS COLD start.

For more information

For more information about this tool, go to the IBM CICS Configuration Manager page.