Skip to content

Promotion And Demotion

Promotion is a ChangeMan ZMF facility that applies the changes in a package to libraries used for testing and other purposes.

Promotion can populate libraries used for:

  • Batch testing where test libraries are coded in STEPLIB or JOBLIB statements in common application testing JCL.

  • Online testing where application testing libraries are coded in region JCL.

  • Unit testing where libraries are loosely controlled and populated by any developer who wants to run a test.

  • Quality Assurance test libraries that must be tightly controlled and can only be populated by the QA testing coordinator.

  • Training environments where software changes must be available for training classes before they are installed into production.

  • Any purpose that requires package components to be copied into a fixed set of libraries.

How Does Promotion Work

Promotion copies components from package staging libraries into libraries that an enterprise uses for application testing or other purposes. Promotion may also be configured to execute additional processes to prepare promoted components for execution. Such processes might include CICS® PHASEIN/NEWCOPY, Db2® bind, and IMS™ gen.

Demotion deletes components from libraries that were populated by promotion. Demotion may also execute processes such as CICS PHASEIN/NEWCOPY, Db2 bind, and IMS gen to adapt an environment to the changes made by demotion.

Each set of libraries that promotion can target is represented by a promotion level. The ChangeMan ZMF Administrator defines promotion levels for each application with the library types that can be promoted and the names of the libraries that are targeted for each type. Library types for promotion usually include the executable components in your package and may also include nonexecutable types like source code. However, a promotion level does not have to include all library types in an application.

Each promotion level is defined under a site. Promotion can populate libraries and prepare executables on local sites, which means environments that are on the same MVS image as the ChangeMan ZMF server. Promotion can also populate libraries and prepare executables on remote sites, which means environments that are on MVS images separate from and do not share DASD with the image where the ChangeMan ZMF server runs.

Full promote and demote operate at the package level. All components in a package that are eligible for promotion are promoted or demoted together. The current promotion level is recorded at the package and the component level.

Selective promote and demote operate on individual components in a change package. The package promotion level remains the same, but the component promotion level changes.

Since application test libraries are often shared with other developers and projects, promotion looks for potential overlays by comparing the names of package components eligible for promotion against the directories of the target libraries. The person promoting the package is given a choice whether to proceed and overlay matching components in the promotion libraries or cancel the promotion request.

Promotion must not be confused with the physical movement of components through a series of test libraries and into production libraries. Promotion always copies components from package staging libraries into target promotion libraries. Likewise, at baseline ripple and install, package components are copied from package staging libraries into baseline and production libraries.

Promotion Library Cleanup

ChangeMan ZMF is delivered with the promotion facility configured to provide the maximum level control over the contents of promotion libraries. Promotion can be configured to satisfy other priority requirements.

In the maximum control configuration, when a package is promoted from one level to another, promotion libraries at the prior level are cleaned up. ChangeMan ZMF deletes the components from the libraries in the prior promotion level, unless a component originally promoted from the package was overlaid by promotion from another package. Promotion libraries are also cleaned up when a promoted package is baselined or

This configuration assumes that promotion libraries used for testing are concatenated in front of baseline libraries or production libraries or copies of these libraries. The objective is to guarantee that if no packages are promoted to a set of test libraries, those libraries are empty, and the test environment behaves exactly like production because it is running only production components.

In some testing environments, such as those that use databases and/or data dictionaries, it is not possible to concatenate promotion libraries in front of production libraries. Components must accumulate in the promotion environment as packages are cycled through development, testing, and install. To satisfy this requirement, ChangeMan ZMF skeletons must be modified to disable promotion library cleanup at promotion, demotion, and install.

Disabling promotion cleanup is not advisable. If promotion cleanup is disabled, the package lifecycle must be carefully analyzed to discover when orphans might be inadvertently left in promotion libraries, and when package components might not be copied to a particular accumulation library at all.

Promotion Security

Each promotion level in an application is associated with a security entity, which is defined in the mainframe security system (IBM RACF®, CA-ACF2®, or CA-Top Secret®). By working with the security administrator to grant or deny userid access to the promotion security entities in the security system, the ChangeMan ZMF administrator can limit who can promote and demote packages in a particular promotion level.

For example, all developers might be permitted to promote packages to a unit test promotion level. Only Quality Assurance test coordinators might be permitted to promote packages to a QA test promotion level.

Promotion Rule

The behavior of the promotion function is governed by the Promotion Rule. The administrator selects a Promotion Rule for each application that provides the level of management for change packages, components, and promotion libraries that is required by the application.

The following table describes how the Promotion Rule determines the requirements for promoting and demoting packages and components.

Rule Restrictions
0 Full and selective promote and demote are allowed without freezing the package first. Requires the following sequence to change a promoted component:
1 - Selective unfreeze (only if the package is frozen)
2 - Edit
3 - Stage ("Restage")
4 - Selective freeze of the component (only if the package is frozen)
5 - Selective promotion to any level up to the package promotion level.
1 Requires that the package be frozen for promote and demote. Requires the following sequence to change a promoted component:
1 - Selective demote of the component
2 - Selective unfreeze
3 - Edit
4 - Stage
5 - Audit package
6 - Selective freeze of the component
7 - Selective promotion back to the package promotion level.
2 Requires that the package be frozen for promote and demote. Requires the following sequence to change a promoted component:
1 - Selective demote of the component
2 - Selective unfreeze
3 - Edit
4 - Stage
5 - Audit package
6 - Selective freeze of the component
7 - Selective promotion through all intermediate levels to the package promotion level.
3 Requires that the package be frozen for promote and demote. Requires the following sequence to change a promoted component:
1 - Full demote of the package
2 - Selective unfreeze of the component
3 - Edit
4 - Stage
5 - Audit package
6 - Selective freeze of the component
7 - Full promotion through all promotion levels up to the original promotion level.
4 Requires that the package be frozen for promote and demote. Requires the following sequence to change a promoted component:
1 - Full demote of the package
2 - Revert the package to development status
3 - Edit
4 - Stage
5 - Audit package
6 - Freeze package
7 - Full promotion through all intermediate levels to the package promotion level.

...

Note

The Promotion Rule does not change the requirements for audit. If audit is required before freeze, then audit is required before selective freeze.

Promotion Rule By Promotion Level

Normally, all promotion levels in all sites in an application are governed by the Promotion Rule coded in application administration parameters.

However, the level of control over promotion usually differs between lower promotion levels used for developer unit testing and higher promotion levels used for systems testing, quality assurance testing, and user acceptance testing.

Exit program CMNEX027 can be used to assign different promotion rules to different promotion levels. This exit can also be used to assign other promotion restrictions to individual promotion levels.

Promotion Rule 0

If the Promotion Rule is set to 0 for an application (or for a promotion level with exit program CMNEX027), many promotion controls are relaxed. These relaxed rules may be appropriate for certain uses like populating libraries used in early component testing.

In addition to the requirements listed in the Promotion Rule table above, the relaxed controls for Promotion Rule 0 include:

  • Components that are not ACTIVE that are in library types eligible for promotion are bypassed and a message is displayed.

  • Re-staging a component sets the component promotion level to 0. The package promotion level is not changed.

  • Package may be promoted to levels that are not the next contiguous level.

    Promotion Rule 0 must be used with caution because it allows different versions of a component to exist in promotion libraries and staging libraries.

First Promote

When a package is at promotion level 0 (not promoted), special procedures apply to the first promotion action. These procedures, specially in combination with Promotion Rule 0, can be useful for promoting individual package components for testing before the entire package is ready for testing.

  • A package component may be selectively promoted when the change package is at Level 0 (not promoted). A selective promote in these circumstances is labeled a first promote.

  • When all components are promoted to the same level as the first promote, the package promotion level is changed to that level. The package may be fully promoted or demoted from this new level.

  • After a first promote, a package cannot be promoted until all components are selectively promoted to that level.

Other Restrictions and Options

These are general rules for promoting and demoting packages and components:

  • Except for first promote, a component cannot be selectively promoted to a promotion level higher than the package promotion level.

  • Except for first promote, the package promotion level is set only by a full promotion. The package promotion level is reset after a full demotion, not after all components have been selectively demoted.

  • A package may not be promoted or demoted if components are at different promotion levels above the 0 level. Components may need to be selectively promoted or demoted to align components at the package level.

  • A package may not be promoted to the current package promotion level. A component may not be selectively promoted to its current component promotion level.

  • Promotion or demotion for local sites is accomplished in one batch job. Promotion or demotion for remote sites requires three batch jobs, one of which runs at the remote location.

  • All promotion jobs that are initiated on the user’s MVS image obtain JOB card information from the Promote Options Panel. Promotion jobs that run at remote sites obtain JOB card information from the Site Definition in application administration. Job names for jobs that run at remote sites may be modified with exit program CMNEX008.

Promotion Paths

When promotion is defined for an application, the administrator creates each promotion level under a site defined in Application Administration.

The administrator can set the Force Demotion field for sites in the promotion definition to allow packages to be promoted to levels in more than one site at the same time. Sites may also be defined so that packages must be demoted in other sites before they can be promoted to levels in that site.

Levels, sites, and the Force Demotion field may be configured to provide multiple promotion paths within the same application. Here are some alternative promotion path definitions.

  • Define each level under a unique site so that the Force Demotion field can be used to allow promotion or any or all promotion levels at the same time.

  • Define all levels under one site to provide a single promotion path for all packages. If there is only one promotion site defined in an application, the promotion function skips over the site selection panel when a package is promoted or demoted.

  • Group promotion levels under several sites to create multiple promotion paths. There might be a path for packages with online system changes and a different path for packages with batch system changes.

  • Use sites for special promotion purposes. A promotion level with training environment libraries as targets might be defined under a unique site. A package containing new software would be promoted to this level on a certain calendar date to support training classes no matter where the package was promoted in other sites.

Approvals and Promotion

Approvals and promotion are separate facilities.

  • Users authorized to promote packages to a level may promote frozen packages to that level no matter what approvals have been granted.

  • Users authorized for approval can approve frozen packages no matter where a package may be promoted.

  • The last approver initiates distribution and/or scheduling regardless of the last promotion level reached.

The package lifecycle always requires approvals. The package lifecycle does not require that packages be promoted before they are baselined and installed.

However, security entities for promotion and approvals may be used to provide a procedure that mixes promotion privileges with approval responsibility, as in the following example:

  • The QA coordinator is permitted update authority to a promotion security entity to allow her to promote packages to the QA test environment.

  • The QA coordinator is permitted update authority to an approval security entity to allow her to enter an approval labeled QA Testing.

The QA coordinator should only approve a package for QA Testing after she has promoted the package, the package has been tested, and she has examined QA test results.

Note

Planned and Unplanned Approval definitions include an Order No. field. When this field is incorrectly called an approval level, users often confuse its purpose with the function of a promotion level.

Promotion Libraries In SYSLIB Concatenations

Library concatenations for SYSLIB DD statements in compile and link edit JCL are automatically built by ChangeMan ZMF skeletons. These skeletons put staging libraries at the top of the concatenation and baseline libraries at the bottom. Promotion libraries are placed between staging and baseline libraries.

You may exclude individual promotion libraries from these SYSLIB concatenations by coding the SYSLIB Exclude field in the promotion library definition in application administration. The SYSLIB Exclude field only has meaning for like-copy and like-load library types.