Skip to content

Release Lifecycle

An ERO release has a life cycle that overlaps the package life cycle in the base ChangeMan ZMF product. This section describes the ERO release life cycle and its relationship to change packages you attach to a release.

Create a Release

ChangeMan ZMF local administrators and ERO release managers make ERO administration entries to create a release.

Release managers execute these ERO functions to create a release:

  • Create a release

  • Add Install Approvers

  • Create Release Areas

  • Add Area Approvers

  • Associate prior releases

ChangeMan ZMF local (application) administrators execute these ERO functions to complete release configuration:

  • Join Application to a Release

  • Define Application Library Types

  • Define SYSLIB Concatenations

  • Define Area Promotion

Attach a Package to Release

Attaching a change package to a release is the first step in bringing components that you are developing or changing into the ERO release life cycle.

After attaching your package to a release, the components in your package remain under package control, and you execute standard change package life cycle functions to prepare these components for installation into production. However, ERO alters package and component behavior.

  • You cannot change the package install date so that it falls outside the range of the release install date.

  • You can check out components from ERO release area libraries in the release your package is attached to, or you can check out components from area libraries in prior releases.

  • Release area libraries for your application and release area libraries for related applications defined in your release are included in SYSLIB concatenations when you stage, recompile, and relink components in your package.

  • Install JCL in the package X node library is created when the release is blocked, not when the package is frozen.

  • Components are installed from release final area libraries, not from package staging libraries.

Notify Area Check-in Approvers

Check-in approval opens a release area for package or area check-in.

Check-in approval notification starts the check-in approval process. Check-in approvals cannot be entered until the check-in approval notification function is executed, even if there are no notifications defined for any of the approvers.

If the approval rule for an area is set to require check-in approval, and there are no check-in approvers defined for the area, execution of the check-in approval notification function sets the check-in approval flag to Y.

Approve Area Check-in

Check-in is an administrative process that grants permission for developers or release managers to populate the libraries for an area through the check-in function. Check-in approval can be used to certify that release areas and applications are properly considered by administrators and release managers.

The requirement for check-in approval is determined by the area approval rule. Check-in approvals cannot be entered until the check-in approval notification function is executed, even if there are no notifications defined for any of the approvers.

If a check-in approver rejects the area, you must execute the Reset Check-in Approvers function. All check-in approvals entered up to that point are cleared. You must initiate the check-in approver notification process, and then enter all check-in approvals again.

Check-in a Package

Package check-in brings components from a package attached to a release into the starting subsystem area defined for that package. This step begins the integration of your package components with other release components that are in development in other change packages across the enterprise.

Package check-in accomplishes these objectives:

  • Allocates area libraries for all areas in the release for the library types that are contained in the package.

  • Populates starting release area libraries.

  • Makes the components available to build processes in other packages in the same application that are attached to the release.

  • Makes the components available to build processes in packages in other applications that have this application defined as a related application.

  • Starts the process of resolving multiple versions of the same component that are in development at the same time and that will be installed at the same time.

Note

The base ChangeMan ZMF product encourages you to manage concurrent development by displaying checkout conflict messages and concurrent development messages. In contrast, ERO guarantees that a release will contain only one version of a component in an application by funneling all components through release area libraries that eventually converge in one set of libraries in the final system area.

Check-in is subject to these rules and conditions.

  • The target release and area for package check-in are predetermined. You define the release and starting area when you attach a package to a release.

  • The check-in rule for the target area determines whether your package must be audited or approved before package check-in is allowed. The check-in rule can also restrict who can perform check-in to the target area.

  • You can check-in all package components, or you can check-in selected package components.

  • The library type of a package component must be defined to the application joined to the target release. Your ChangeMan ZMF administrator makes those definitions. If the library type is not defined in the joined application, check-in is skipped for those components.

  • If a package component already exists in the target area library, you must explicitly override a “check-in components disallowed” condition to overlay the component.

  • A component in an area library can only be overlaid by the person who checked in the component, and it can only be overlaid if it is checked in from the same package. This rule can be overridden in the definition of the target area.

  • If a component that already exists in an area library cannot be overlaid, it must be retrieved before it can be checked in again.

Check-in an Area

Area check-in copies components from the libraries for one area into the libraries for another area. Check-in advances release components through the hierarchy of areas that progressively integrate release components.

Area check-in accomplishes these objectives:

  • Populates the area libraries for the next area defined for the release.

  • Makes the components available to build processes in other packages in the same application that are attached to the release.

  • Makes the components available to build processes in other packages in the same application that define this release as a prior release.

  • Makes the components available to build processes in packages in other applications if this application is defined as a related application.

  • Continues the process of squeezing out multiple versions of the same component that are in development at the same time and are intended for install at the same time.

Note

The base ChangeMan ZMF product Checkout encourages you to manage different versions of the same component that are in development at the same time by displaying checkout conflict messages and concurrent development messages. In contrast, ERO guarantees that a release will contain only one version of a component in an application by funneling all components through release area libraries that eventually converge in a set of libraries for the final system area.

Check-in is subject to these rules and conditions.

  • The target area for area check-in is predetermined. When you define an area in a release, you specify the next area.

  • The check-in rule for the target area determines whether the area must be audited or blocked before check-in to the next area is allowed.

  • The check-in rule for the target area can restrict who can perform check-in to the target area.

  • A single check-in operation copies components from a set of release area application libraries into the corresponding set of area application libraries in the next area. If there are several applications joined to a release, you perform multiple check-in operations to copy all area components to the next area.

  • You can check-in all components from a selected application, or you can check-in selected components from a selected application.

  • If a component already exists in the target area library, you must explicitly override a “check-in components disallowed” condition to overlay the component.

  • A component in a target area library can only be overlaid by the person who last checked in the component to the target area. This rule can be overridden in the definition of the target area.

  • If a component that already exists in an area library cannot be overlaid, it must be retrieved before it can be checked in again.

Audit an Area

ChangeMan ZMF maintains the integrity of the components and applications under ERO control through the Release Audit, which is more sophisticated than the package audit delivered with the ChangeMan ZMF base product.

Release Audit examines the components in libraries for a particular release area, as well as libraries for other areas in the release, libraries in prior releases that will be installed sooner, and baseline libraries. It evaluates relationships between different versions of the same component, and it evaluates relationships between components and other components they include like copybooks and statically linked load modules.

See Auditing Release Areas.

Block an Area

Blocking an area locks the area down to prevent further changes to area components. When an area is blocked, you cannot check-in components to the area.

The blocking rule for an area determines whether audit is required before the area can be blocked. The area blocking rule can also restrict who can block the area.

Other area rules can make release area functions contingent on the block status of an area. The retrieve rule for an area can be set to prohibit retrieve from an area that is blocked. The area check-in rule can require that an area be blocked before it can be checked in to the next area.

All areas must be blocked before a release can be blocked.

Notify Area Check-off Approvers

Check-off approval signifies that an area is ready for check-in to the next area.

Check-off approval notification starts the check-off approval process. Check-off approvals cannot be entered until the check-off approval notification function is executed, even if there are no notifications defined for any of the approvers.

An area must be blocked to notify check-off approvers.

If the approval rule for an area is set to require check-off approval, and there are no check-off approvers defined for the area, execution of the check-off approval notification function will set the check-off approval flag to Y.

Approve Area Check-off

Check-off approval is an administrative function that grants permission to check-in the contents of area libraries to the next area.

The requirement for check-off approval is determined by the area approval rule. Check-off approvals cannot be entered until the check-off approval notification function is executed, even if there are no notifications defined for any of the approvers.

Note

The requirement that the area be blocked before check-off approval notification can be executed overlaps the function of the area check-in rule that sets requirements for to the next area. One of the options of the area check-in rule is to require area block.

If a check-off approver rejects the area, you must unblock the area. All check-off approvals entered up to that point are cleared. You must initiate the check-off approver notification process, and then enter all check-off approvals again.

Block a Release

Blocking a release locks down the release and its areas in preparation for install. All areas in a release must be blocked before a release can be blocked, and all packages attached to the release must be approved.

When you attempt to block a release, ERO executes a pre-install test to validate the release and the contents of the final release area. (Release components are installed from final area libraries.) These are some of the conditions that are detected in the pre-install test.

  • Install date of attached package outside of the release install date range.

  • Attached package not in APR status.

  • Component checked in from an attached package, but not checked in to the final release area, and not deleted from the package.

  • Different versions of a component in the attached package and the final release area.

  • Attached package that has no components.

If the pre-install test detects no errors, notification is sent to the approvers with the lowest install approver order number, and the release is blocked. Install JCL in the package X node library is created when the release is blocked.

Approve a Release for Install

After a release is blocked, all install approvers must enter their approvals before the release will install.

When the last approval is entered, the release status is changed to APR.

Backing Out a Release

Release backout first verifies that all packages attached to the release are in a state that permits package backout. Then release backout submits package backout jobs from the X node libraries for the packages attached to the release. After all packages have been backed out, the packages and the release are in BAK status.

Reverting Release

Revert release clears all release install approvals, unblocks the release, and changes the status of the release from APR or BAK to DEV status. The status of release areas is n