Skip to Content

[ZMF Administrator]

Printer-friendly version

Lesson 1: Xnode datasets for install / backout

ChangeMan ZMF uses a set of PDS members to perform the installation (or later the backout) of a package (in a selected local or remote site).


Add ILODs to like SRC SCRATCHes

When you enter a scratch request of a like source, ChangeMan ZMF may or may not add one or more additional scratch requests to the package automatically.


Structure of the Z-Factory topics

For each item (topic) in any of the Z-Factory categories categories, the information about it consists of the detailed problem description, and th



Create powerful CMN/ZMF reports or charts without any programming

Z-Consults Categories

Dr. Chgman's Z-Consults categoriesAll items (topics) available within the Z-Consults area, are classified by category, i.e.:


Verify and allocate promo, baseline and prod DSNs in appl admin

It takes quite some effort to ensure (verify) that for each ChangeMan ZMF application all DSNs defined as promo-, prod- or baseline DSN are allocated (with the appropriate LRECL, etc), and if not get them allocated. Not doing so will cause promotion and/or installation jobs to run into JCL errors (DSN not found) or system abends (because of invalid DCBs). Wouldn't it be great if you could automate this labor intensive task and reduce/simplify the required effort to just migrating a (special) change package which, on the fly, verifies and allocates all appropriate DSNs?


Use custom ISPF tables in CMN/ZMF's FTINCL

Despite the dozens (if not hundreds) of admin parameters that can be defined in ChangeMan ZMF admin (global admin or application admin), mostly every ChangeMan ZMF customer always needs more of such variables. They are typically needed to specify system DSNs, subsystem IDs, region identifiers, etc. Hardcoding all appropriate values in ISPF skeletons is an option to consider, but it is a real pain to maintain such skeletons. Similar to what can be done via ChangeMan ZMF admin for DSNs related to DB2 or IMS processing, a more elegant solution is needed ...


Add restart instructions in Xnode jobs

In case of a failed installation of a change package, the failing job (typically the CMN10, CMN20, CMN21 or CMN30 job) needs to be restarted, after the reason for the failure has been addressed. Such restart typically needs to be initiated by operations control people (and quite a lot during non-business hours). To actually perform such restart, these people often encounter quite some difficulties that need to be addressed somehow:


Verify VSAM datasets as 1st step of STC proc

According to the ChangeMan ZMF manuals you should always shutdown the started task with the modify command to “orderly shutdown”, which then also ensures the correct closing of the VSAM files.

However, there are a few occasions where this simply does not happen, like:


Common skeletons, includes, EXECs, etc

To tune (customize) the delivered ChangeMan ZMF software, or to introduce "new" customized components, you will find yourself coding the same set of lines of code over and over. A few samples to illustrate this:

  • jobcard info.
  • STEPLIBs, JOBLIBs, SYSEXECs, SYSPROCs, etc that have concatenations with site specific DSNs.

Especially in vendor supplied ISPF skeletons there are a lot of hardcoded values (like DSNs, etc) that require customization. Apart from the issue about these traditional site dependent DSNs, etc (which you find in virtually any vendor software), you also have larger chunks of ChangeMan ZMF specific ISPF skeletons that are repeated in lots of skeletons over and over. Partially because they have not been developed with the ChangeMan ZMF skeleton coding techniques in mind.

By grouping together all such code, you can reuse such components over and over again.

Syndicate content