Concepts
Before using CICS® Configuration Manager, you need to understand its basic concepts. The following list is a condensed introduction. For more detailed information, see the topics on each concept.
If you do not plan to use change packages to migrate resource definitions between CICS environments, the only new concept you need to understand is the CICS configuration:
- To insulate you from the differences between CSD files and CICSPlex® SM contexts, CICS Configuration Manager introduces CICS configurations. A CICS configuration is a name that you use to refer to the location of resource definitions, instead of the data set name of a CSD file or the name of a context. When using CICS Configuration Manager, instead of referring directly to CSD files or contexts, you refer to CICS configurations, and CICS Configuration Manager handles the underlying differences. Before you can use CICS Configuration Manager to work with resource definitions, you need to define a CICS configuration for each of the CSD files or contexts in which those resource definitions are stored.
If you plan to use change packages, you also need to understand the following concepts:
- Typically, organizations migrate resource definitions between environments according to well-defined paths: for example, from development to the test environment, and then from test to production. In CICS Configuration Manager, you define these migration paths in migration schemes. Each migration path identifies a pair of source and target CICS configurations. A migration scheme can define several migration paths.
- To migrate a change package, you select the appropriate migration scheme, depending on the environments that you want to migrate between. For example, to migrate a change package from development to the test environment, you select a migration scheme whose migration paths refer to your development CICS configurations as the source and your test CICS configurations as the target. To migrate a change package from test to production, you select a migration scheme that refers to test as the source and production as the target.
- A change package identifies a set of resource definitions that you want to migrate, a set of commands that you want to migrate, or both. Adding a resource definition or a command to a change package is known as packaging.
- A change package can refer to resource definitions in several CICS configurations. Migrating a change package migrates only those resource definitions that are in the source CICS configurations of the selected migration scheme. Any other resource definitions in the change package are ignored.
- You can also package the following commands:
- Add
- You can use the Add command in a change package to perform the
following tasks:
- Add a resource definition to a resource group (ResGroup) in a context-based target CICS configuration
- Add a ResGroup to a ResDesc (by RESINDSC association)
- Add (append) a CSD-based group to a list
- Remove
- You can use the Remove command in a change package to perform
the following tasks:
- Remove a resource definition from a ResGroup
- Remove a ResGroup from a ResDesc (by RESINDSC removal)
- Remove a CSD-based group from a list
- Delete
- You can use the Delete command in a change package to perform
the following tasks:
- Delete a resource definition from either a CSD-based or a context-based target CICS configuration
- Delete a ResGroup from a context-based target CICS configuration (if the ResGroup contains resource definitions, the Delete command fails)
- Delete a group from a CSD-based target CICS configuration (deletes all of the resource definitions in the group)
- Before migrating a change package, you must mark it as ready. This prevents you from migrating unexpected changes (such as edits to resource definitions that occurred after you marked the package as ready).
- After migrating a change package, CICS Configuration Manager automatically adds to the change package any migrated resource definitions and commands. This behavior is known as propagation. Propagation allows you to reuse a change package with different migration schemes, progressively migrating resource definitions and commands from one environment to the next: for example, from development to test, and then from test to production.
- You can undo ("back out") change package migrations.
- Change packages can require approval by up to five approver roles defined in an optional approval profile.
- Migration schemes can refer to transformation rules that can alter resource definition attributes and commands during migration, or block migration of certain resource definitions and commands.
- You can use a change package to perform install, discard, or newcopy actions on active CICS regions.
- Instead of referring to a CSD file or a context, a CICS configuration can refer to an export file. You can copy or migrate resource definitions to an export file, transfer the export file to a separately managed system at a remote site, and then import the resource definitions into a CSD file or a context on that importing system. If you migrated (rather than copied) the resource definitions to the export file, then the export file preserves the change package details, enabling you to "register" (re-create) the change package on the importing system, and continue migrating it onwards through the environments on the importing system. You can also migrate commands to an export file.