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.