Skip to Content


Printer-friendly version

Using the STUB panel in CMN/ZMF

Document the usages of ChangeMan ZMF's STUB panel, which will be shown it you type primary command S on ChangeMan ZMF's primary option menu (and you've been authorized to use it).


Enable user defined edit macros in CMN/ZMF

Document what it takes to enable your own set of edit macros to be invoked when using edit in staging, together with some typical use-cases for it (i.e. to launch non-standard ISPF editor session, also called exotic editors).


Missing package activity dates (invalid restarts)

Package activity dates are dates that are stored in ChangeMan ZMF's meta data (CMNPMAST), and which relate to events such as:

  • When did this package enter the status FRZ, DIS, INS, BAS, etc.
  • When did some target production site confirm that the package was distributed to that site, or installed in that site.


Missing, empty or forgotten staging libraries

Staging libraries are the data sets related to a change package in which ChangeMan ZMF stores its changed components. Together with the meta data of the package and the components in it (both stored in ChangeMan ZMF control files like CMNPMAST), they actually constitute the change package. And the ChangeMan ZMF started task (server running on the mainframe) will take care of managing all such staging libraries: they get created (by ChangeMan ZMF) whenever they are needed, and they get removed during housekeeping, after the package became INS/BAS.

Here are some issues about these staging libraries:


Dead checkouts and dead stage requests

A checkout is used to get a copy from the current production version of a component (or variations like the previous version or the upcoming nearly-GA version), so that you can start a new version of it. But what about all those checkout requests that happened long time ago (a few days, weeks, months or years ago), and which are still in the same checkout status (= creating a new version of it has not yet started yet)?


Empty packages

A change package is assumed to contain changed components and/or scratch requests (in 2 decades we have not ever found 1 ChangeMan ZMF customer that's using the rename function, so let's skip that one). Fine, but where do those empty (= no components + no scratch requests) packages come from?


Non-BAS packages not moving anymore

Change packages follow a life cycle, starting from the creation of it, up to the installation of it into production (and optionally followed by a backout it needed). That's the theory, and also what happens most of the time.

However consider some change package that was created by some ChangeMan ZMF user, whereas such package is not yet installed in production (not BAS yet). What happens with such package if the ChangeMan ZMF user quits the company (variation: moves on to another job within the company)?


Limbo packages with install date passed

Anybody knows this issue, which is about all non-BAS packages that have a planned installed date that's somewhere in the past. It's entered on the last panel to create a package, or updated via the U7 panel.


Lesson 4: Products complementing CMN/ZMF's XML services

After completing the previous lessons in this course, it will be clear that the XML services in ChangeMan ZMF are an extremely powerful set of functions. But it will also be clear that there are quite a few challenges (missing features, etc) to use these XML services successfully.


Lesson 3: Exploring the XML universe

Dr Chgman's Training about XML services in ChangeMan ZMFTo actually start using the XML services, probably the biggest challenge is to become aware (and learn how to use) each of the available XML services.

This lesson starts with providing a functional overview of all available XML services, with an overview organised corresponding to the major ChangeMan ZMF concepts like administration, packages and components. Afterwards some special XML services (utilities and transfer facilities) are explained.

Syndicate content