Skip to content

Introduction

ChangeMan ZMF

ChangeMan® ZMF protects corporate software assets by automating the development process, resulting in higher application quality and increased application availability. It’s a comprehensive solution that provides reliable and streamlined implementation of software changes in a z/OS environment.

Since ChangeMan ZMF controls every code change, it guarantees source-to-load integrity and makes sure that only successfully tested programs make it into production. By moving code through an automated life cycle with strict accountability every step of the way, ChangeMan ZMF reduces regression errors and maintenance costs.

Protecting Production and Development

ChangeMan ZMF answers the question, “What is production?” by including all development and test environments within the controls traditionally applied only to production execution libraries.

ChangeMan ZMF is granted exclusive update access by your security system to baseline and production libraries, and exclusive update access to libraries in controlled test environments. ChangeMan ZMF creates and manages the staging libraries where developers check out and modify application components.

The components in all of these libraries are protected by restricting access to the ChangeMan ZMF functions that can change the contents of these libraries. Developers, approvers, testing coordinators, ChangeMan ZMF administrators, and others can execute only those functions in ChangeMan ZMF for which they have been granted authorization by your security system.

All functions in ChangeMan ZMF are subject to rules defined in ChangeMan ZMF administration. Processes are consistent and repeatable to the extent that your ChangeMan administrators define rules that constrain user choices and options.

Change Package

A ChangeMan ZMF change package is a unit of work for application component changes being made for a project.

A change package consists of descriptive information, control parameters, and history information stored in ChangeMan ZMF VSAM master files. A set of staging libraries that belong exclusively to the change package contain application source, load, and other components that are being changed.

A change package is a secure development environment for project components. Access to a package and to package components is managed by ChangeMan ZMF using rules stored in your security system.

Rules in ChangeMan ZMF administration set constraints on options for managing components in change packages. Other administration rules restrict options for managing change packages through the change package life cycle.

Package components remain in package staging libraries throughout the ChangeMan ZMF package life cycle. Components are copied from package staging libraries to test libraries for testing, and components are copied from staging libraries to production libraries for installation.

Change Package Life Cycle

The change package life cycle is rules-based process consisting of:

  • Actions that developers, approvers, testing coordinators, and others perform on change packages and change package components

  • Processes that are automatically initiated by ChangeMan ZMF when certain conditions are met

Authority to perform actions in the package life cycle is controlled by ChangeMan ZMF and defined in your security system. Rules in ChangeMan ZMF administration define what options are available in the change package life cycle.

The steps in the change package life cycle include the following:

  • Create Package is the first step in the change package life cycle. Using a series of input panels, screens, or windows, you enter information that describes the change package, and you set control parameters that determine how the package behaves during the rest of the package life cycle.

  • Checkout Component copies components from a baseline or promotion library into a staging library allocated exclusively to your package. You can also check out components to a personal library, which is tracked by ChangeMan ZMF.

  • Stage Component is where you edit and build package components to meet project requirements. Source components are processed through predefined build processes to create executables and build listings. You can also stage components into your package from libraries outside of ChangeMan ZMF to bring those components under the control of ChangeMan ZMF.

  • Package Audit detects problems that will occur in production if you install your package in its current condition. Audit detects synchronization problems between components in your change package, and it detects synchronization problems between package components, components in participating packages, components in promotion, and baseline components.

  • Freeze Package locks package information and package components to prevent further changes and to ensure that the components you install into production are the same as the components you tested. You can selectively unfreeze, change, audit, and refreeze components to fix problems found in testing.

  • Promote Package copies package components from staging libraries into test libraries. As a package is promoted from one testing level to the next, package components are removed from libraries in the prior level and copied from staging libraries into test libraries for the next level.

  • Demote Package removes package components from test libraries.

  • In Approve Package, predefined approvers review package information, components, and test results and approve or reject the package for install. If an approver rejects the package, they enter text Reject Reasons.

  • Revert Package removes all previously entered approvals, unlocks package information and components, and opens the package back up to development.

  • Distribute Package occurs if you are installing a package through another ChangeMan ZMF instance at a remote site. It starts automatically when all package approvals are entered for a package. The package is transmitted to the remote site where package records are added to the ChangeMan ZMF instance running there, package staging libraries are allocated and populated, and the package is added to the internal scheduler.

  • Install Package starts automatically, either when the package install date and time arrive, when the last approval is entered, or when an external job scheduling system triggers the first installation job. If the application has production libraries that are separate from baseline libraries, current production modules are backed up and new versions are copied from package staging libraries into the production libraries.

  • Baseline Package starts automatically after a package is installed. This process ripples current and prior versions of package components down in a stack of prior baseline versions, and then copies package components into the baseline libraries as the new current version.

  • Backout Package removes package components from production libraries and restores the backups made when the package was installed. Package components that are the current version in baseline libraries are removed, and components are reverse rippled up the stack of prior baseline versions to restore the old current version.

SERNET

SERNET (previously called SERENA/Network) provides communication and other services on the enterprise server for Serena products. SERNET runs as a started task on an LPAR.

ChangeMan ZMF runs as an application under a SERNET instance. Other products, such as ChangeMan® ZDD, run on other platforms and use a SERNET instance to gain access to mainframe files and services. If the library ZDDOPTS is used, see the ZDD or ZMF4ECL Server Installation Guide for further information.

The diagram below is a logical view of the SERNET architecture. It shows two SERNET instances on separate LPARs, each managing a ChangeMan ZMF instance. Users access these ChangeMan ZMF instances from TSO sessions in the z/OS environment, ChangeMan ZDD running on a Windows workstation, or from ChangeMan ZMF for Eclipse running on an Eclipse workstation. The TSO user in the last LPAR is using the Load Balancing Option of ChangeMan ZMF to work from a mainframe environment where there is no SERNET or ChangeMan ZMF instance.

Serena SERNET Architecture with ZDD and ZMF4ECL Interfaces

Implementation Strategy

ChangeMan ZMF is designed to be flexible so that it can serve customers who have a broad range of data center standards and change management requirements. A byproduct of that flexibility is that there are choices you must make before you configure ChangeMan ZMF to manage components in your development and production environments.

These choices include:

  • How you will define applications in ChangeMan ZMF

  • How you will configure baseline and production libraries in relation to those applications

  • What kind of package approval process you need

  • What roles you want people to play, and what authority they will require to access ChangeMan ZMF functions

  • Whether you will create multiple ChangeMan ZMF instances to manage production application components across your enterprise

These issues are discussed in the first few chapters of the ChangeMan ZMF Administrator’s Guide, and additional details are found in the Administrator’s Guide chapters that tell you how to configure Global and Application Administration. Your organization needs to examine these issues and find consensus among developers, development managers, testing groups, data center operations, security, EDP audit, IT management, and business partners.

You can help these groups understand the issues and the alternatives available by installing ChangeMan ZMF and bringing up a test or demonstration ChangeMan ZMF instance where you can show them how ChangeMan ZMF works. As you reach tentative decisions about the configuration want to use, you can change your initial settings in administration, create new applications, or build new ChangeMan ZMF instances to test your design.

You can also use information in the ChangeMan ZMF Customization Guide to explore exit programs and skeleton modifications to satisfy your requirements.

This Installation Guide tells you how to install ChangeMan ZMF components and make entries in your security system so that you can bring up a ChangeMan ZMF instance.

When you get a ChangeMan ZMF instance running, it is recommended that you use the instructions in chapter “Setting Up Global Administration” and chapter “Setting Up Application Administration” in the ChangeMan ZMF Administrator’s Guide to set up the simplest ChangeMan ZMF configuration possible, accepting system defaults where they are available and using the most liberal parameter settings possible.

When you have configured global and application administration in ChangeMan ZMF, create some simple JCL and source components in the new baseline libraries. These components do not need to be executable, but the source code must compile successfully.

Use the instructions in the ChangeMan ZMF User’s Guide to create a change package with no components, and process this empty package through the change package life cycle. Next, create a package and check out components into the package. Stage some simple source components so you can see compile and link edit processing. Process the package through the life cycle.

Use this incremental approach to exercise more and more features of ChangeMan ZMF as you gain knowledge of how you can implement ChangeMan ZMF to meet your requirements.

If you license one or more ChangeMan ZMF selectable options, use the installation instructions in the Getting Started Guide for each of those options to add those facilities to your test or demonstration instance of ChangeMan ZMF. Experiment with those options to decide how you want to implement them.