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!

Many of the skeletons used to create the jobs in the Xnode DSNs contain a lot of ISPF DOT-statements, which actually build the various member lists for the components to be installed or backed out. The format of these member lists differ: for the same set of components there are lists to copy, delete, etc.

In a recent ChangeMan ZMF release (well, actually quite some years ago ...), already quite a few of the ISPF DOTs to build these memberlists were removed. This because they were replaced by the creation of some &&&&-datasets in the beginning of each X-node DSN. Even though this was a great step forward in enhancing performance of FTINCL (which is known to be using quite some resources), it was simply not enough (since each Xnode job still has some steps to create those &&&&-datasets). What is worse: it did not enhance the restart ability of the X-node jobs (since a failed job needs to be restarted from recreating the &&&&-datasets now, and not from the failing jobstep).

When installing hundreds of change packages (e.g. for enterprise wide releases), the process of (re-)building the Xnode jobs becomes very resource intensive and time-critical. In certain occasions it even leads to S069 abends in the CMNxADSP jobs that actually build those Xnode DSNs (by invoking FTINCL). Sure these S069 abends (that are not easy to detect or diagnose and even tougher to get resolved) are the result of incorrect values used as ASID-parms in the ChangeMan ZMF started task, but does anyone actually know the most appropriate values for them?

While searching for a solution for all this, you may as well try to solve these issues that are somehow related to it:

• Enhance (simplify) the restart ability of the Xnode jobs (from failed jobstep, instead of restarting from the beginning of the failed job, where those &&&&files get created, and which may even lead to overlaid backup libraries).
• Prevent the migration of $$$SPACE members in staging libraries (typically added to these libraries when they are managed by PDSMAN) into promotion, production or baseline libraries.

Consider the approach to address this issue as documented in the Z-Clues (login required).