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

Here are some illustrations why such extra variables are needed (they often relate to other system software packages that ChangeMan ZMF interacts with):

• to manage certain CICS regions (into which ChangeMan ZMF is configured to issue CICS new copy commands during promote, demote, install or backout)?
• to invoke FTP software (C:D, Netview FTP, etc.) as part of CMN10, CMN14, CMN24, etc.
• to perform,  as part of the promotion or install processing, special actions within a non-DB2 DBMS (such as IDMS).

One way to implement this, is to use some type of hard coding in skeletons. But that makes the customizations harder to understand and maintain. If you decide to go for this hard coding in skeletons anyway, at least you should consider the approach described in Use ASZ$$VAR in any ChangeMan ZMF submitted job.

A much more elegant approach, which avoids this hard coding in skeletons, is the use of custom ISPF tables. These tables are made available to ChangeMan ZMF whenever file tailoring is done. Consider the approach to address this issue as documented in the Z-Clues (login required).