Why resource definitions need managing

Every CICS® region refers to a set of resource definitions. Typically, organizations maintain each of their CICS regions in at least three separate environments: development, test, and production. Changes to resource definitions are migrated from development to test, and then from test to production. As shown in Figure 1, even if each environment contains only one CICS region, this means three sets of resource definitions, and two migrations to move each change into production.

Figure 1. Migrating resource definitions between development, test, and production CICS environments

Begin figure description. The figure is described in the surrounding text. End figure description.

Real-life systems are typically much more complex, but even a simple system such as this raises issues. For example, if your developers enhance a CICS transaction, requiring a new resource definition for an additional file:

How do you migrate the new resource definition from development to production?
Do you simply copy the complete set of resource definitions from one environment to another?
What if the resource definitions in each environment are intentionally different? For example, what if the high-level qualifiers for the file are different in each environment (DEV., TEST., and PROD.): do you edit the resource definitions for each environment separately?
How do you ensure that you migrate only the changes that are ready for migration?
What if some environments are controlled by CICSPlex® SM, but not others? Do you need to use different tools to update these environments?
How do you back out a change?
How do you keep a systematic record of changes, for reporting and auditing?
How do you avoid overwriting unexpected changes in the environment you are migrating to?
How do you compare resource definitions?
Who approves the migration?

These issues grow as your CICS system topology becomes more complex. Your organization might have several development, test, and production environments, with different numbers of CICS regions in each environment, and a variety of migration paths.

You might have resource definitions that are shared by regions in one environment, but not in another. So you might need to migrate resource definitions not just from one CSD file to another, but also from one CSD file to many. For example:

Your development environment might combine the typical CICS responsibilities of application owning, file owning, and terminal owning into a single region, with resource definitions stored in a single CSD file.
Your test environment might assign these responsibilities to separate regions (AOR, FOR, TOR) sharing a single CSD file.
Your production environment might have separate CSD files for each AOR, FOR, and TOR.

As shown in Figure 2, when migrating from a shared CSD file to unshared CSD files, you need to ensure that you migrate the resource definitions to the appropriate locations.

Figure 2. Migrating resource definitions from shared to unshared CSD files

Environments with many CICS regions often use CICSPlex SM, which stores resource definitions in data repositories rather than CSD files. So you might need to migrate resource definitions between CSD files and contexts in CICSPlex SM data repositories:

Figure 3. Migrating resource definitions from CSD files to CICSPlex SM data repository contexts

CICS Configuration Manager addresses all of these issues.