Skip to Content

[1.0-Orval]

Printer-friendly version

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?

READ MORE

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.

READ MORE

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?

READ MORE

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

READ MORE

Add restart instructions in Xnode jobs

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:

READ MORE

Verify VSAM datasets as 1st step of STC proc

According to the ChangeMan ZMF manuals you should always shutdown the started task with the modify command to “orderly shutdown”, which then also ensures the correct closing of the VSAM files.

However, there are a few occasions where this simply does not happen, like:

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

READ MORE

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.

READ MORE
Syndicate content