Skip to content

Key Terms and Concepts

ERO (Enterprise Release Option) introduces new terms and concepts to ChangeMan ZMF.

Release

A release represents a collection of ChangeMan ZMF simple change packages from any number of applications that must be installed at the same time. In ERO, a release is a logical set of rules for relating the physical elements of a release. These elements are:

  • the baseline libraries of the applications

  • the release libraries

  • the staging libraries of the change packages

Releases are managed by a Release Manager, who has exclusive authority over the release creation and life cycle. Release managers can get real-time information about components within releases online.

When you create releases, you define release install date and time ranges. All packages you attach to a release must have install dates within the release install range.

Figure 3-2. Releases are created with installation date and time ranges.

When you create a release, you define prior releases. This information can be updated as additional releases are added.

Figure 3-3. You define prior releases when you create a release.

Release Area

A release area is a set of component libraries that represents a migration step in the release life cycle. Each area has its own set of dynamically allocated libraries based on application and library type. The default data set name format for release area libraries is:

HLQ.ReleaseID.AreaID.ApplID.Libtype

The consolidation of components takes place in these release area libraries, which are used in SYSLIB concatenations for build processes in release packages. They are also used by release audit to validate release component relationships.

A minimum of two release areas are required. A starting area is used to check package components into a release. The final area is used to move the release into production, and it must contain the entire release. For a typical release, you define one or more starting areas, multiple intermediate areas, and a final area.

...

Figure 3-4. Releases require a minimum of two areas.

Starting areas are subsystem areas. Final areas are system areas. Intermediate areas can be either subsystem areas, which can be subordinate to subsystem and system areas, or system areas, which can be subordinate only to other system areas.

Area definitions include fields for prior and next areas, and approvals may be required for migration from one area to another. If you specify check-in approvals, they must be granted before components can be checked in to an area. If you specify check-off approvals, they are required before components can be migrated into the next area.

As components are migrated from one area to another, prior area libraries remain fully intact. This differs from base ChangeMan ZMF package promote, where package components are removed from libraries in the prior level.

Release Migration Path

The release migration path is defined by the prior and next areas specified in each release area definition.

Release area definitions include fields for prior and next areas. Starting areas, which serve as the entry point for packages, have only next areas, while final areas serve as the production migration point and have only prior area definitions. Additional areas can have both prior and next areas. You define as many areas as you need to establish your release migration path.

In the following diagram, Start Area has no prior area, but has one next area (Area2). Area2 is defined with a prior area (Start Area) and a next area (Area3). Likewise, Area3 is defined with a prior area (Area2) and a next area (Final Area). Final Area is defined with one prior area (Area3), and has no next area.

Figure 3-5. Release migration paths are defined when you link areas.

You can define multiple migration paths within a release. Multiple starting areas migrate to other areas, gradually combining until they come together in a single final area. Installation copies components from the final area into production and updates the baseline libraries of the applications in the release. The baseline update process ripples current and prior versions of package components down in the stack of prior baseline versions. The package components are then copied into the baseline libraries as the new current version.

In the following diagram, Team1 and Team2 changes are migrated and consolidated to the Group1 area, and Team3 and Team4 changes to the Group2 area. Both Groups are migrated and consolidated to the Integration area before migration to the Final Area. The Fixes Area is used as a quick path to the Integration and Final areas.

Figure 3-6. Multiple migration paths can be defined in a release.

As shown in the diagram above, you can set up migration paths for change requests, which follow a longer and more robust migration path, as well as fixes, which require a shorter process to production.

Release Application

An application becomes a release application when it is joined to a release.

Applications are joined to a release by an applications administrator, who also chooses what library types from each joined application are included in the release. By restricting library types in a release, administrators can build special purpose releases. For example, an online release would contain only the library types associated with CICS components. A batch release would contain library types associated with JCL and batch processing.

Figure 3-7. Applications are joined to a release.

By joining applications to a release, the application administrator can define:

  • the applications that are included in the release

  • the library types to include

  • the SYSLIB concatenation

  • the library types shared between applications in build processing

Release Package

You create a release package when you attach a simple change package to a particular release that has a starting area defined. The install date for a release package must fall within the range of the install dates defined for the release. When you attach a package to a release, ERO takes control of building the SYSLIB concatenations for build jobs.

If components in area libraries must be changed, you make the changes in package staging libraries using the familiar ChangeMan ZMF procedures. Package check-in, a subsequent step, will then bring the changed components from a package into the starting area.

Figure 3-8. Simple change packages are attached to a release.

More information