Skip to Content

[Helpdesk operator]

Printer-friendly version

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!


ChangeMan ZMF Xnode members + jobflow

To perform an install/backout or a promote/demote, ChangeMan ZMF uses a set of data sets for executing all required jobs.

  • The member names of these PDS members, which follow a certain naming convention.
  • The jobs contained in such PDS members (to actually promote, install, demote, backout, etc), and how they get triggered (jobflow).
  • Jobs that run locally (on the DP site) and jobs that run remotely (on the target site, if using remote sites).
  • Jobs that are always executed, and jobs that are only executed based on some conditions.
  • How to tune (customize) ChangeMan ZMF to create and submit your own additional PDS members in such data sets.
Duration (hours): 

Add restart instructions in Xnode jobs

A possible solution to eliminate these difficulties is to add restart instructions in all appropriate Xnode members, so that these instructions are available in any job listing of any Xnode job that may have to be restarted.


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 ...

Syndicate content