Skip to content

Inside ChangeMan ZMF Development

Behind the displayed ChangeMan ZMF panels, there are jobs being performed that ensure the smooth flow of enhancements to each application maintained by development analysts.

Create

Create is the first step of the ChangeMan ZMF lifecycle. After you create a change package, ChangeMan ZMF allocates staging libraries as needed. The data set names of the staging libraries reflect the application mnemonic chosen for your application, the package number assigned for this change, and the type of components placed in the library; for example, demo.cmnstage.#000023.src. The Global Administrator decides on the format of the data set name. The package information is recorded on the package master along with the TSO ID of the creator. A record of this event (package creation) is placed on the log.

Checkout Process

Checkout is the process of copying components from the baseline library (any level back or from promotion libraries) to a staging library or a development area outside of ChangeMan ZMF for modification in a change package. You can check out online or in a batch job. If you check out in batch mode, ChangeMan ZMF asks you to verify (initially type or update) the jobcard statements needed to perform the batch job.

When you check out a component, the standard ISPF statistics are carried forward and the version number (the vv portion of vv.mm) is incremented. ChangeMan ZMF adds the checkout information to the statistics that make up the component history. A record of this event (checkout component) is placed on the Activity Log. Anyone can browse this log for information not only on checkout actions, but also other ChangeMan ZMF activities.

When you associate the checkout to a valid change package ID, the component name is added to the package staging list. This means that when you select the stage option from the Build Options Menu and select to stage from the Package Driven option, the component is already listed with a checkout status.

Staging Process

Staging introduces components into ChangeMan ZMF by copying them from development or personal libraries into ChangeMan ZMF staging libraries. All staging library components must be associated with pre-defined change packages.

Depending on how your administrator configures staging parameters for your site, you can either stage any newly created application component into any change package, or only components previously associated with (that is, checked out to) change packages.

For instance, your administrator may want to restrict new development on an application and designate that only existing components be maintained. The administrator can restrict the staging process so that only components previously associated with change packages can be staged back into the change cycle.

Before staging, verify that your administrator has:

  • Assigned compile procedures for each language type you intend to stage.

  • Assigned appropriate compilers during installation of ChangeMan ZMF.

    Staging libraries contain components of the same type. The following table lists component types that ChangeMan ZMF recognizes and considers when staging.

Type Description
SRC Source modules
LOD Load modules
JCL JCL
DOC Documentation
CPY Copybooks
LCT Linkage Control Cards
LIKE SRC, LIKE LOD, LIKE CPY Assign this type to SRC, LOD, or CPY components when you want to stage components of same type into separate staging libraries.
LIKE N Like-NCAL: NCAL load subroutines. Once staged they are concatenated in the SYSLIB for links within the same package (if the lib type is present in the package).
LIKE O Like-Object: Object code subroutines. Once staged they are concatenated in the SYSLIB for links within the same package (if the lib type is present in the package).
OTHER Assign this type to components when you want to customize processing of a component.
PRC Compiling procedures

You can stage components online, or stage them in batch.

Staging Type Enables User to Do the Following:
Online Use confirmation panels to review relevant parameters and compile procedures prior to staging a component.
Use language assumption (a feature that automatically assigns language types) and designated compile procedures when staging source components.
Batch Stage multiple components simultaneously.
Stage complete libraries of components.
By-pass confirmation panels to stage components faster.
Use the language assumption feature.

Auditing

When you audit a package’s staging libraries, ChangeMan ZMF analyzes and reports on every module contained in your change package with respect to the baseline versions. The Audit function also validates all copies and program calls, producing a report listing all duplicates and out-of-sync conditions. (Audit also includes copybook promotion libraries when generating the hash token table.)

Freezing Packages

When you are ready to freeze the package for promotion (optional) and approval (required), ChangeMan ZMF checks two things:

  • Are all components in an Active status?

    During the stage process, if the component is successfully copied into the appropriate staging library and if source components have compiled, link/edited, and their bind has completed successfully, then ChangeMan ZMF changes the status of the component to Active.

  • Did the package pass the audit?

    The audit level selected by the application's administrator must not be exceeded.

    When the package is successfully frozen, the status of the package changes from DEV to FRZ, which locks out anyone from staging into the package libraries. A record of this event (freeze package) is placed in the Activity Log.

Promoting Packages and Components

The Promotion facility allows you to set up intermediate environments or promotion levels where you can perform quality assurance, unit, and system tests on packages and components.

Promoting involves migrating change packages or components through these intermediate environments. Demoting is the deleting of components logically or physically from these environments.

Before using the Promotion facility, your application administrator must first set up:

  • Promotion levels. You can have one or more levels of promotion, each level having one or more libraries associated with it.

  • Promotion process. You can promote packages and components online or in batch.

  • Promotion authorization. Each promotion level can be secured. Your administrator can build rules in ChangeMan ZMF and your security system that designates which users can promote a package to a specific level.

    Generally, you promote packages from staging libraries to specified promotion levels.

    The following functional characteristics of the Promotion facility may affect decisions you make about when and how to promote and demote packages and components:

  • After components are copied from package staging libraries, they still reside in the staging libraries. This implies that you should only include executable libraries in your promotion environment. Source modules do not have to be promoted because they will be retained in the package libraries.

  • Promotion from level to level may be a logical copy or a logical move; that is, the components may remain in the previous environment, or they may be deleted from the previous environment upon promotion.

  • Each time you promote (or demote), ChangeMan ZMF updates the statistics constituting the component history. A record of this event (promote package) is placed in the Activity Log.

  • Staging skeletons for source components may reference promotion copybook libraries as part of the copybook concatenation. Therefore, if copybooks are promoted, they may be made available to source compilation of other packages.

  • ChangeMan ZMF does not require the use of promotion, even if it has been set up by an administrator. Moreover, upon completion of the approval process, the package is distributed (and installed) regardless of the level of promotion reached. This gives you the flexibility to alter the path of migration of each package. However, if you do want to require a promotion path, you can administratively link your promotion security to your approval security. This technique allows a promoter to submit approval of a package once it has been successfully promoted and tested.

Approving Packages

When a person accesses the ChangeMan ZMF panels, that person’s TSO ID is passed along and used to determine which functions are available. Approval may be performed only by those TSO IDs associated to the entity names that the application administrator specified as approvers.

  • The approval process consists of browsing the package information and staging libraries for quality control and standards and selecting to Approve (or Reject) the package.

  • A record of this event (Package Approval) is placed in the Activity Log. The package status is changed from FRZ to APR.

  • All approvals for a package must be gathered before ChangeMan ZMF Installs a package. In fact, the final approval of a package actually initiates or schedules the package Installation.

  • A change package must be in frozen (FRZ) status to be approved or rejected.

  • In general, a package’s components cannot be modified while in frozen status. This implies that a package’s components cannot be modified while approvals are being gathered. Components can be selectively unfrozen, modified, and refrozen while the package is still in frozen status.

  • There can be multiple levels of approvals. ChangeMan ZMF requires at least one approval, but allows administrators to set up more than one level.

  • Multiple levels of approval can be set up in a hierarchy. ChangeMan ZMF enforces an order of approvals, and does not allow approvals to be gathered out of order.

  • More than one User ID can be authorized to satisfy a given approval level. This is set up in your security system.

  • Your application administrator may have set up approval notifications. Each approval level can be configured with multiple User ID notifications. The User IDs that are notified may or may not coincide with the User IDs that can actually satisfy the approval.

  • Different packages may have different approvals. ChangeMan ZMF allows administrators to set up separate approval Lists by application and by time of day. ChangeMan ZMF attaches an abbreviated approval list to unplanned packages created outside of normal business hours, and a complete approval list to all other packages. Your administrator may have tailored a user exit to customize approvals lists further.

  • ChangeMan ZMF provides special processing for packages with an abbreviated approval list attached. These approvals must be gathered before the package can be Installed. Once installed, the package continues to be available for approval or rejection by approvers on the complete approval list. This allows for a post-installation approval strategy.

  • Packages can be promoted and demoted while approvals are being gathered. The final approval of a package Installs it, regardless of the promotion status. Therefore, the final approver of a package should be sensitive to the promotion activities of packages.

  • If a package is rejected, it must be reverted if it is to be updated to conform to the reject reasons. A package revert action resets the rejection and places the package in development status. The package must then be frozen again to reinitiate approvals.

  • If a package was promoted before it was rejected, it must be demoted before it can be reverted.

  • Package revert resets any gathered approvals. This is true regardless of whether or not the package is first rejected.

Installation

Installation depends on whether or not an internal scheduler is set up by the global administrator, or if the Install job JCL has been modified. There are four variations on Installation:

  • If no scheduling system is specified, the package goes through the installation process immediately.

  • If the Install job JCL is set up with a TYPRUN=HOLD, the user releases the job when they are ready to install.

  • If a scheduling system other than the ChangeMan ZMF internal scheduler is specified, then ChangeMan ZMF performs a batch interface to add the install job to the scheduler's list. The operator, however, must still demand the job for the package to be installed.

  • If ChangeMan ZMF is the scheduler, it checks the package master every few minutes for any packages that are ready and installs those that meet the criteria.

Backing Up

Backup is the first job to be performed when installation time arrives. This job copies the production libraries (only those components that are about to be overlaid with updates) to a backup set in case they are needed to back out the incoming enhancement. Next, the contents of the change package staging libraries are copied into production libraries. A record of this event (package installation) is placed on the Activity Log. This occurs each time the package is Installed at one of the remote sites.

Once the package is verified as Installed in all requested sites, the following steps are performed:

  1. The package status is changed from DIS to INS (or from APR to INS if there are no remote sites).

  2. A job is sent to the development center to clear out the last level of promotion reached, and to ripple the baseline libraries for that application.

  3. The package status is changed from INS to BAS.

  4. A record of the baseline ripple is placed in the log.

Note

Only the various versions of changed software components are updated; ChangeMan ZMF ripples the changes through the versions of an application's baseline libraries.

Assume that the following is true:

  • An application maintains up to three versions of its baseline library software: current(0), -1, and -2.

  • You want to update the baseline libraries with a change package in which component A is changed, component B is scratched, and component C is added.

  • There already is a -1 and -2 version of component A. Thus, the baseline library is updated as follows:

  • The -1 version of component A is copied to overlay the -2 version of component A.

  • The 0 version of component A is copied to overlay the -1 version of component A.

  • The newly-installed version of component A is copied from the production staging libraries to overlay the baseline library 0 version of A.

  • Component B is scratched.

  • The newly installed version of component C is copied from staging libraries and added to the baseline 0 libraries.

Backing Out Packages or Components

If there is a problem with the change package after it has been Installed, the change package is backed out by deleting the updated component in production, and then retrieving the previous version of application software from the Backup library. This option is selected by an authorized user in the production environment (usually an operator or production analyst).

ChangeMan ZMF backs out the entire package by copying the components from the backup libraries to overlay production, including components that have been scratched. The package status is changed from BAS to BAK. A record of the package backout is placed in the Activity Log.

A job is submitted in the development area to reverse ripple the baseline library. A record of the baseline reverse ripple is placed in the Activity Log.

Temporary Change Cycle

When a temporary change package is created, the user must type the number of days the change is to remain in the temporary (override) environment (if your global administrator has setup this option). The installation process is different from other package types because the contents of the temporary change package staging libraries are copied into temporary libraries (which are concatenated ahead of production libraries). Because the production library components are not touched, ChangeMan ZMF does not perform the hot backup.

The components are never rippled into the baseline library. After the package is Installed, ChangeMan ZMF begins the aging process at each site selected to receive the temporary change. The components in the temporary library are deleted when the number of elapsed days is met. If you use a scheduler, the job automatically runs. If you use a manual scheduling method, the job is submitted on hold, and must be released when the duration of days is met. After the package is deleted from all sites, its status is changed from INS to TCC, and a record of this event (Temporary Change Cycle Completed) is placed on the Activity Log.

Distribution to Remote Sites

The next step after approval depends on the environment type configured for the site.

  • If there are remote sites, then the package staging libraries, the installation JCL, and a copy of the package master records pertaining to this change are distributed (copied) to all the sites specified in the creation/update package process. A record of the package distribution is placed in the Activity Log, and a distribution acknowledgment is sent back to the development center. The package status is changed from APR to DIS.

  • If remote sites exist, the package is ready for installation. For further information, see Installation

Distributing and Installing Components at Remote Sites

Remote sites are additional CPUs where ChangeMan ZMF installs components. An additional CPU can be:

  • A separate computer in another building

  • A separate computer in the same building

  • A logical CPU on the same machine as part of an LPAR (logical partition) without shared DASD

    Any of these remote site configurations enables you to develop components on one CPU, and distribute and install production-level components on a different CPU.

    Remote sites act only as receivers of production level components. The only time developers interact with remote sites is when they select which remote site to distribute and install production level components.