Migration of resource definitions

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

Figure 1. Overview of change package migration
Edit
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.
Package
You "package" resource definitions by adding them to a change package. This allows you to migrate a set of resource definitions together.

In addition to packaging resource definitions that refer to individual resources, such as programs and files, you can also package lists (sets of groups, as defined in CSD files). You can then migrate the lists from one CICS configuration to another. This enables you to manage changes to lists across CICS systems. Some restrictions apply to packaging lists that do not apply to other resource types: you cannot migrate a list to a CICS configuration that refers to a context. Also, note that packaging a list only adds the list object (a set of group names) to the change package, not the groups in the list.

Ready
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.
Approve
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: all of the applicable approver roles must have approved the change package.

Approval is not a "for/against" voting system: approver roles either approve a change package, or withhold approval. An approver role can only disapprove a change package that they have previously approved: disapproving the change package removes the approval.

Unready
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. If any approver roles had approved the change package before it was marked as unready, then, when you mark the change package as ready again, these approvals are removed, even if none of the resource definitions in the change package have changed since it was first marked as ready.
Migrate
When you issue the command to migrate the change package, CICS Configuration Manager:
  1. Confirms that the change package is still ready (has not changed since you marked it as ready, and has not been marked as unready).
  2. If approval is required: confirms that the change package is fully approved.
  3. Reads the candidate resource definitions from the source CICS configurations, and transforms them according to the rules specified by the migration scheme.
  4. Writes 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).
  5. Adds the migrated resource definitions to the change package. This allows you to reuse the change package with different migration schemes to progressively migrate resource definitions between environments.

    For example, suppose you package a set of resource definitions in your development environment, and then you migrate the change package using a "development-to-test" migrate scheme. CICS Configuration Manager automatically adds to the change package the migrated resource definitions in the test environment. You can then migrate the same change package onwards to production using a "test-to-production" migrate scheme.

Roll out versus back out

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, the 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.

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

Figure 2. Migrate command processing

Information Information

Feedback


Timestamp icon Last updated: Friday, 1 November 2013


http://pic.dhe.ibm.com/infocenter/cicsts/v5r1/topic//ccv-migration.htm