Skip to Content


Printer-friendly version

Replace IEBCOPY by SERCOPY where possible

A lot of ChangeMan ZMF submitted jobs like promote, demote, install, backout, etc. typically suffer, occasionally, these kinds of IEBCOPY related issues:


Secure CMN/ZMF panel commands via entity checks

There are some ChangeMan ZMF functions in ChangeMan ZMF's ISPF dialog that are typically NOT allowed to be used by just any developer, e.g. because they may impact the integrity of  ChangeMan ZMF managed projects. Some examples are:

  • Revert a package back to development when the approval process has not been started (= not even 1 approval has been given), because in that case revert is allowed by anybody with application update access (and the CMNxREVR / CMNREVRT entity is not checked!).
  • Setting certain user options to some special value (e.g. some Y/N flag to skip some validation in the staging job).
  • A scratch request is commonly considered as a dangerous ChangeMan ZMF feature, because of the known  ChangeMan ZMF issues related to using scratch request, e.g.:  ChangeMan ZMF audit does not include any validations related to scratch requests.
  • A selective unfreeze (followed by edit-in-stage and re-freeze) of components in a successfully audited and frozen package, which may introduce inconsistencies for which no built-in controls exist in ChangeMan ZMF to prevent them.
  • ...

Just a complete disable of a function like 'unfreeze' (or utility request 'rename') might be an option in certain cases, which is typically done by just remove it from the ISPF panels. But how can you implement something to restrict access to such functions (without removing them entirely)?


ASR Runtime Environment for Z-Reports

Creating new ChangeMan ZMF reports, and or customizing any of the reports delivered with ChangeMan ZMF has always been a challenge. Mostly because it requires expertise in the REXX programming language and you need to have 'some' experience in using ChangeMan ZMF's (green) XML services. On top of that, ChangeMan ZMF does not come with any out-of-the-box charts (only reports).

Therefor, in most ChangeMan ZMF implementations, all such reporting (and charting) requests from any type of , gets routed to the (usually overbooked) ChangeMan ZMF administrators who might either not have the required REXX and/or XML experience, or don't really like to do such reporting work. Not to forget the effort that may be required when upgrading to a new ChangeMan ZMF release ...


User defined relationships

Create a SCMBeans solution to make ChangeMan ZMF create and maintain a Bill Of Material for selected (like source) library types, using a technique that was first introduced in AbitMORE SCM for IDMS/ADSO.

This Bill Of Material can then be used:


Analyse the content of a package

Many ChangeMan ZMF processes (like checkout, promote, install, etc) perform special processing for specific library types, and this via special jobsteps. Quite often this is implemented using all sorts of ISPF skeleton customisations. That's why in skeletons like CMN20, CMN30, CMN50, CMN$$RPM, etc you will find a lot of coding with lots of ')SEL' and ')DOT' statements, to process specific library types. As time goes by, more and more of such coding is added, which makes those skeletons hard to maintain, and which also makes performance (of FTINCL) go down (not to speak about increasing CPU resources). So what can you do to keep control over this type of skeleton customisations?



Reusable software components to facilitate developing additional CMN/ZMF customizations

Dr Chgman's SCMBeans for ChangeMan ZMFREAD MORE

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.


Simplify CMNBAT90 - SERCOPY usage to activate components

Staging processes for like source components typically produce one or more staging outputs (so called 'ILOD' related components). For each library type, this is done via 2 jobsteps that perform PGM=CMNBAT90, followed by a jobstep with PGM=SERCOPY.

Syndicate content