Skip to content

Area Promotions

ERO area promotion is built on low level ChangeMan ZMF services, originally developed for package promotion, to make it possible for you to:

  • Use the promotion sites, levels, and libraries that you have configured in application administration in the base product.

  • Execute special functions like Db2 binds and CICS PHASEIN that you have enabled in promotion skeletons.

The use of low level package promotion services makes area promotion similar to base ChangeMan ZMF package promotion in some ways and different in other ways. Some characteristics of area promotion that are important to keep in mind include:

  • With area promotion, staging libraries are not referenced when promoting to sites and levels defined to ERO. Area promotion jobs copy components from area libraries into target test libraries.

  • You can demote components that are no longer in an area if they were retrieved after they were promoted.

  • You select area components for promotion by application. If an area contains components from more than one joined application, you must perform more than one promote or demote action to promote or demote all components checked in to the area.

  • If you select area components for promotion that were checked in from two different packages, area promotion submits a separate job or series of jobs for each package.

  • There is no area promotion history. Area promotion activities are displayed in package promotion history available through the query package function.

  • The behavior of area promotion is controlled by a indicators set in ERO administration. Area promotion ignores package promotion rules set in the base product, and Exit 27 is not invoked.

  • You can fully demote a package whose components have been promoted with area promotion. This function is made available to simplify the process of detaching a package from a release, which required demoting and retrieving all package components.

Area Promotion Behavior

Area promotion ignores the promotion rules in application administration in the base ChangeMan ZMF product, and Exit 27 is not invoked. Area promotion behavior is determined by promotion site/level definitions inherited from application administration and by four behavior rules you set for each application / area / site / level combination that you define in ERO administration.

Inherited Definitions and Rules

These definitions and rules are inherited from application administration when you use a site/level definition from the base ChangeMan ZMF product to build an application / area / site / level definition in ERO area promotion. You cannot modify these in ERO administration:

  • Site Name

  • Force Demotion Rule - Determines if an area can be promoted to a site if it is already promoted to another site.

  • Internal Reader Class - Used for submitting local and remote promotion jobs.

  • Level Nickname

  • Level Number

  • Promotion Level Security Entity - Determines who can promote to a promotion site/ level and demote from that site/level.

  • Procedure - The high level skeleton used by file tailoring to build promotion job JCL.

ERO Area Promotion Behavior Rules

You set these four rules in ERO administration when you define a application / area / site / level combination in ERO administration. You cannot change these rules for an application / area / site / level combination if any area components are promoted to that level.

  • Area Check-in Approved - Determines whether an area must have all check-in approvals before area components can be promoted.

  • Area Blocked - Determines whether an area must be blocked before area components can be promoted, and whether all area components must be demoted before the area can be unblocked.

  • Area Check-off Approved - Determines whether an area must have all check-off approvals before area components can be promoted.

  • Demotion Required For Retrieve - Determines whether you must demote a component before you can retrieve the component.

Promotion Jobs and Messages

If an area contains components from more than one application, you must perform an explicit promote or demote action for each application. Each explicit promote or demote action you take may submit multiple jobs, or multiple series of jobs in the case of remote sites.

  • Area promotion submits a job or series of jobs for each package whose components were checked in to the area being promoted or demoted.

  • The area promote or demote job(s) for a single package may be split into multiple jobs or series of jobs if the number of components being promoted or demoted exceeds the capacity of the promotion service.

    When multiple area promotion jobs are submitted for components from the same package, MVSSEND success messages are suppressed until the last job completes successfully. Failure messages are sent from any area promotion job that fails, and the failure message includes the release area and package ID to help you promote or demote again the components in the job that failed.