Skip to Content


Printer-friendly version

Only show promotion candidates in selective promote

For at least a decade or so, there is a feature available in ChangeMan ZMF (probably from around version 5.3 or so) which is more or less "hidden" in CMNEX027, with a very misleading comment in it. It appears that hardly anybody knows about that hidden feature. By turning it on, during selective promote ChangeMan ZMF will only show a subset of components that can be promoted. I.e. it will only show components that fit any of these criteria:


Clone components via stage from development (S1)

Nobody ever starts developing a new program (component) from scratch, typically everybody always starts from a copy of an existing component. Just performing a checkout from baseline is not a solution, because you cannot change the member name, the library type or the application you are checking out from).

To take this even a step further: the (existing) component to be cloned may or may not have the same library type, and typically resides in either of these libraries: 

  • In a staging library of the same package or another package.
  • In a baseline library of the same application or another application.

So how can you do this cloning in ChangeMan ZMF?


Temporarily disable FRZ, REV and APR

Sometimes a certain group of ChangeMan ZMF users (like ChangeMan ZMF admins, release managers, …) need to perform a special operation (usually planned, though sometimes unplanned). To do so, it may be that during such operations certain ChangeMan ZMF operations (e.g.: package freeze, package approve, revert to DEV, etc) cannot be used by any ChangeMan ZMF user. Shutting down ChangeMan ZMF entirely obviously is an option. But what about those situations where just shutting down the entire ChangeMan ZMF system (for a few hours or so in the middle of the day?) is not an option?


Locate a component in CMN/ZMF libraries

Test environments typically use concatenations of promotion (or shadow) libraries concatenated ahead of production (or baseline libraries). When an application in a test environment produces unexpected results, it is usually caused by old versions of a component still hanging around in one of the promotion (or shadow) libraries  in the concatenation list. That's where the ChangeMan ZMF helpdesk calls typically come in.


Use ASZ$$VAR in any CMN/ZMF submitted job

ChangeMan ZMF uses the CMN$$VAR skeleton to set various skeleton variables used within staging jobs (only). This solution introduces a similar skeleton, ASZ$$VAR, which can be used (embedded) in any phase in the ChangeMan ZMF lifecyle for which a job is submitted.


Add restart instructions in Xnode jobs

Lesson 2: Using XMLSERV for prototyping

Dr Chgman's Training about XML services in ChangeMan ZMFThis lesson teaches the use of XMLSERV, an  ISPF dialog that comes with ChangeMan ZMF and that can be used for XML prototyping.

The lesson also explains some deficiencies about XMLSERV, and explores some alternatives to XMLSERV.


Lesson 1: Getting started with XML in ChangeMan ZMF

Dr Chgman's Training about XML services in ChangeMan ZMFThis lesson starts with an historical overview of where the XML services in ChangeMan ZMF originate from, after which some basic concepts of XML in general are explained.

The lesson then explains of how the use of XML is implemented in ChangeMan ZMF via its SERXML-clients, and how each XML service can be narrowed down to a common anatomy.


Keep LSTs readable via unique &&LISTxyz

If you do NOT always have unique &&LIST-DSNs to store staging outputs (like SYSPRINTs) in the compressed listing (using PGM=SERPRINT), you'll end up with a compressed listing where multiple staging outputs are mixed together within the same (hard to read) area of the compressed listing. So how can you automatically prevent this from ever happening again?


Create memberlists to improve Xnode processing

The ChangeMan ZMF Xnode DSNs are the jobs that are created by ChangeMan ZMF, typically during freeze and/or final approve, to perform all life cycle steps starting from distribute, install, etc. For each package, one such DSNs gets created for each remote site in which the package is to be installed.

The process to create the members (jobs) in the Xnode DSNs is based (heavily) on ISPF's file tailoring services (FTINCL for short). These services allow you to easily customize the content of all those Xnode jobs using straight forward ISPF skeleton customizations. You can even create your own Xnode members!

Syndicate content