Skip to content

ChangeMan ZMF Library Environment

Checkout

Checkout enables you to reintroduce components that reside in baseline or promotion libraries to the change cycle. Generally, production-level components are checked out for modification. You can check out any previous version of a baseline component that exists.

Depending on the way your administrator configured ChangeMan ZMF, you can check out components:

  • To personal libraries.

  • To staging libraries.

  • Only if they are associated with change packages.

  • In batch.

  • Online.

  • Concurrently with other developers.

    If your site has applications that require parallel development, you can configure ChangeMan ZMF to allow concurrent checkout of components. ChangeMan ZMF has an automated process for managing this concurrent development. As part of this process, ChangeMan ZMF ensures that each owner of a version is aware of the actions of the other owners.

    After you check out components and make necessary modifications, ChangeMan ZMF records the components and the associated change package for further impact analysis. This ensures that your developers are always working with the proper version of a component.

Impact Analysis

To analyze the impact of changes, many organizations rely on data from a variety of sources, such as batch library scans and cross reference files. This method makes it difficult to maintain all sources of data and ensure that they are current. ChangeMan ZMF provides a comprehensive facility to capture, query, and enforce relationships between components.

These relationships include not only the traditional ones, such as a source and executable relationships, but other relationships based on common references to copybooks, SQL Include components, CA Panvalet ++INCLUDE components, CA Librarian - INC components, called subroutines, and JCL fields such as program name, filename, or data set name.

Staging

Staging is the process of introducing newly-developed or previously-developed components into the ChangeMan ZMF change cycle for modification or enhancement, and packaging them with related change package components. When you stage a component, ChangeMan ZMF recognizes the type of component that you are staging and copies it into a staging library of the corresponding type (source, load, JCL, documentation, copybook, and so on.). Staged components are also associated with a pre-defined change package, the vehicle ChangeMan ZMF uses to move components through the change cycle and track the history of change management activities for each staged component.

In change management systems other than ChangeMan ZMF, staging libraries are merely pre-production holding areas shared by one or more application groups. After components are tested in development libraries, they are copied into staging libraries prior to production implementation.

ChangeMan ZMF staging libraries, however, are more than pre-production holding libraries. Components can be modified and tested in protected ChangeMan ZMF staging libraries. When you stage source components, they are compiled, and the resulting load modules are identified, helping you to maintain the integrity of source-to-load relationships.

ChangeMan ZMF maintains up-to-date records of all staging activities for packages and components. For example, when you stage a source component, ChangeMan ZMF records the time that the component was staged, the name of any associated load modules or copybooks, and the compiling procedures and linkage parameters used during the compile. This information is kept in the ChangeMan ZMF master file (the package master). You can view this component and package information by using the query function.

ChangeMan ZMF further extends the concept of staging by isolating components from other changes in progress. This prevents uncontrolled and unknown copybooks and subroutines from being inadvertently referenced, allowing parallel or concurrent development without the risk of accidental overlays. The stable coexistence of multiple versions of a single component simplifies the blending of changes.

Audit

The ChangeMan ZMF audit process ensures correct synchronization of components and procedures. Because of the range of features offered by the package master and the impact analysis database, ChangeMan ZMF maintains control of current and past modifications and component versions. Potential production problems can be identified before they impact production.

The audit function inspects the staging library contents of an evolving change package (in the DEV/FRZ status) with respect to baseline library contents. The inspection looks for situations such as a package that shows no change from the baseline library, or a package that contains a LOD component that does not match its SRC component. Recognizing these situations (called out-of-sync components), ChangeMan ZMF helps you to detect code that is inconsistent with your development procedure and other code problems.

Examples of out-of-sync situations include:

  • Copybooks that were changed after a source program was compiled.

  • Source programs that must be recompiled due to a copybook change.

  • Called subroutines that were changed after a referencing source program was compiled and linked.

You can specify if you want an audit, and if so, whether or not you want to correct or ignore uncovered problems.

You can use audit to analyze the staging library contents of an evolving change package with respect to baseline contents, for the purpose of finding any out-of-sync situations.

The recompile function resolves certain types of out-of-sync conditions found during the audit. The allowable audit return code is determined during global and application parameter generation, and you are not allowed to freeze the change package without passing the audit return value entered for the application.

Using the relink option, you can relink load components without associating them with source code.

The relink process is similar to compile because you select a component from a baseline list. A new load component is produced and copied into the package staging library.

Use the delete function to remove recompiled or relinked components that do not have associated source in the package. You can also delete the resulting LST file and any other non-load components that were associated with it through the CMNBAT90 service. (See your administrator for details on this service.)

The component history is picked up from the history record for that component in the package master. For example, the relink picks up the user options on CMNUSR01 that were there when the program was last relinked.

When relinking, you can include LCT cards that contain the link control cards from staging or baseline libraries, or you can dynamically generate them if there is no LCT component available. You do this if you:

  • Do not have source code for a component, but make a change to a subroutine.

  • Must perform a composite link where the resulting load component name does not have accompanying source.

Freeze

Another unique ChangeMan ZMF feature is the ability to freeze change packages. When the change package is ready for the next phase of the change implementation lifecycle, a freeze is performed to prevent further modifications. The freeze also positions the change package for promotion or approval. Traditional methods accomplish this function by moving components from the development libraries to a separate set of libraries or, in some cases, separate environments. With ChangeMan ZMF, however, the ChangeMan ZMF instance controls your updates in conjunction with your security system, so component movement is no longer necessary.

If further modifications are required, you can unfreeze a change package, and the approval process is reset.

Promotion

ChangeMan ZMF can promote change packages through multiple, shared, pseudo- production promotion environments. These promotion environments are secured as if they are production, and ChangeMan ZMF controls all updates.

ChangeMan ZMF considers shared promotion environments to be places where full integrated system testing can be performed. When the time comes for a full system or an integrated system test, authorized approvers promote the acceptable components into the promotion environments.

When testing is complete and the change package is approved, ChangeMan ZMF (optionally) removes the components from the promotion environments. All production installation occurs from the change package staging environment. With ChangeMan ZMF, you define your testing methodology and the number of testing levels that are required.

Approve

Approvals for change package installation are performed online, eliminating the requirement for manual approval processes. During the ChangeMan ZMF approval process, authorized approvers can indicate that the change package is acceptable for production implementation, or they can reject or review the change and generate a checklist of questionable or unclear items.

ChangeMan ZMF relies on your security system. ChangeMan ZMF does not use internal personnel tables. Approval lists of specific User IDs or approving entities are defined to your security system so that electronic signatures can be collected.

For each application, multiple approvers can be included in an approver list. Separate approval lists can be created for scheduled planned changes or unplanned emergency changes, or you can choose to use an approval hierarchy. With ChangeMan ZMF, you have the flexibility to make these choices.

Production Installation

ChangeMan ZMF is involved in the management and control of production component installation. Component installation can be automated through the ChangeMan ZMF internal scheduling system, or through a direct interface with a job scheduling system. In addition to component movement, ChangeMan ZMF performs other production installation activities such as Db2 Plan binding.

ChangeMan ZMF also has a change quantity threshold facility that allows you to control the number of changes that occur in a time period. For example, you may want to limit the number of change packages that are installed during month-end processing.