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:

• logon to the appropriate LPAR where the restart should be submitted from. That's not obvious to find out, especially because:
  • CMN10 runs on the D(P)-site.
  • CMN20 (and CMN21) run on the P-site.
  • CMN30 runs on the D(P)-site.
  • not to speak about CMN11 (P-site), CMN14 (P-site) and CMN15 (D-site).
  • or CMN24 (P-site) and CMN25 (D-site).
• locate the correct PDS member in the (distributed) Xnode DSN. The XNODE DSN reflects the package ID and complies to the staging model DSN, but this DSN typically also has a name on the D(P)-site that differs from each of the remote P-sites.
• use the appropriate userid (or surrogate user) to actually be allowed to submit such restart. Think about ChangeMan ZMF's security architecture, which assumes that the ChangeMan ZMF started task:
  • is the only user with update authority to any DSN managed by ChangeMan ZMF.
  • has special authorizations to perform DB2 binds, ACBgens, etc.
• decide about the jobstep from where the job should be restarted. Ideally this should be from the failing jobstep, but vanilla ChangeMan ZMF uses quite some temporary DSNs in its CMN10-, CMN20-, CMN30-, etc jobs.

Consider the approach to address this issue as documented in the Z-Clues.