To measure the progress of upgrading all customizations during a ChangeMan ZMF 7.x upgrade project, I've created a ChangeMan ZMF report that our manager seems to like a lot. It took me about 2 (maybe 3?) minutes to "develop" it, using AbitMORE SCM Reporting.

Let's start with a little background info: all customized components currently in production (used in a pre ZMF 7.x release like 6.1 or 5.6) are managed by a traditional CMN-on-CMN application. At the beginning of this upgrade project, we did a checkout of all customized components to about 5 change packages (e.g.: the customizations related to housekeeping jobs are in a separate package, the vendor version V7R1M2 was staged in a separated package, etc). And we entered scratch requests in these packages for any customized components that seem to have become obsolete (the more we can scratch, the smaller the amount of components to be upgraded).

To get an idea of my progress, I'm not interested in the actual component names (for that I just look into the package). But instead, I want to know the number of components for each type of component (like SKL, JCL, REXX, etc). And I want to get an idea, for each type, about their status in these packages, whereas that status is one of those:

• Checkout (= we've not done anything to upgrade it).
• Active (= upgrade is completed, or no changes needed).
• Scratch (= the customization has become obsolete).

Here is how the report looks like:

***************************** Top of Data ******************************
Date: 06/08/12         CMN/ZMF upgrade progress          Time: 18:32:17
                                                                        
  Cmp type: CTL Subtotal:       16                                      
  Cmp type: JCL Subtotal:       30                                      
  Cmp type: MSG Subtotal:        1                                      
  Cmp type: PNL Subtotal:        1                                      
  Cmp type: PRC Subtotal:        6                                      
  Cmp type: REX Subtotal:        7                                      
  Cmp type: SRC Subtotal:        3                                      
  Cmp type: TBL Subtotal:        1                                      

Cmp status: ACTIVE   Subtotal:       65                                 

  Cmp type: JCL Subtotal:       48                                      
  Cmp type: PNL Subtotal:       11                                      
  Cmp type: REX Subtotal:       41                                      
  Cmp type: SKL Subtotal:      110                                      
  Cmp type: SRC Subtotal:        3                                      

Cmp status: CHECKOUT Subtotal:      213                                 

  Cmp type: JCL Subtotal:        2                                      
  Cmp type: PNL Subtotal:       14                                      
  Cmp type: REX Subtotal:       76                                      
  Cmp type: SKL Subtotal:       23                                      

Cmp status: SCRATCH  Subtotal:      115  

Created using AbitMORE ® SCM Reporting 3.1.0 www.AbitMORE-scm.com

**************************** Bottom of Data *****************************

What the report above tells me:

1. we currently have about 400 components we need to consider for this upgrade. 115 of them (over 25 % !!!) are confirmed already that we can scratch them (extra bonus: no more similar upgrade effort required for the future ZMF releases also).
2. we have 65 components that are ACTIVE already, over 15 %.
3. we have about 200 (out of about 400, so around 50 %) of components that we still have to investigate and potentially upgrade them to the new release.

I've chosen to ask for just a traditional (old fashioned) summary report on the mainframe (that's where we're actually working on the upgrade, within ChangeMan ZMF of course). But I wouldn't be surprised if our manager in the very near future would ask me for some nice graphics about it (pie charts, etc). If that happens, I just run (resubmit) the very same report with the option to produce a CSV file, and with the option turned on to have that CSV file eMailed to (e.g.) my manager as attached file. That way he can just open it in his favorite spreadsheet application (or his iPad if that's where he reads his eMail ...).

Also interesting is the fact that the data in the report are actually live data, and not data that are extracted from some "cached" version of the ChangeMan ZMF meta data, residing on some database server. Because reports and graphs based on cached data are like driving your car with a GPS with data that tells you where you were 24 hours ago ... (a comparison I learned from a friend, also ZMF admin, last week). Moreover, actually running the job that creates this report is a matter of seconds (elapsed).

And since my manager may want a daily updated version of it, he just has to get my report generation job scheduled for automatic execution (I'd suggest somewhere during non-business hours, so he has it waiting in his mailbox every morning ...). Should he want to do so, he can even maintain version of the CSV files on the mainframe (as many as he wants) ... in ChangeMan ZMF's well know stacked reverse delta format.

For more details about AbitMORE SCM Reporting, e.g. the typical report variations that fit in the category Developer Reporting, checkout the AbitMORE SCM website about it.

It's fun upgrading ChangeMan ZMF, especially if you can delegate the reporting on your progress to AbitMORE SCM Reporting ... (and stop your manager nagging you to get an idea about the progress you're making).

And it's even more fun knowing that we also have AbitMORE SCM Commander available to get this upgrade job done (e.g. to simplify scanning all customized components, using an out-of-the-box solution that comes with it to scan all components in a package for a specific string, a kind of ISPF 3.15 where you scan multiple staging libraries in 1 shot, but where you don't have to first look up all the staging DSNs that exist in that package (but that's another topic we might soon write about in another posting).

In case you're also working on upgrading to ChangeMan ZMF 7.1.x these days and you're interested in learning what it takes to start running a similar report in your own ChangeMan ZMF environment (including the optional CSV format for your manager ...), checkout our Z-Reports On Demand offerings.

Update about the above report (about a month later): Guess what, we're finished with (most of) the customization upgrades. Here is how the above report looks like right now:

***************************** Top of Data ******************************
Date: 06/09/12   CMN/ZMF upgrade progress (excl. DOCU)   Time: 15:36:35 
 
  Cmp type: CLD Subtotal:        2 
  Cmp type: CLW Subtotal:        2 
  Cmp type: CTL Subtotal:       82 
  Cmp type: JCL Subtotal:       30 
  Cmp type: MSG Subtotal:        1 
  Cmp type: PNL Subtotal:       11 
  Cmp type: PRD Subtotal:        2 
  Cmp type: PRW Subtotal:        4 
  Cmp type: REX Subtotal:       43 
  Cmp type: SKL Subtotal:      118 
  Cmp type: SRB Subtotal:        6 
  Cmp type: TBL Subtotal:        1 
Cmp status: ACTIVE   Subtotal:      302 
 
  Cmp type: JCL Subtotal:       18 

Cmp status: CHECKOUT Subtotal:       18 
 
  Cmp type: CTL Subtotal:        3 
  Cmp type: JCL Subtotal:       16 
  Cmp type: PNL Subtotal:       15 
  Cmp type: REX Subtotal:       77 
  Cmp type: SKL Subtotal:       33 

Cmp status: SCRATCH  Subtotal:      144 
 
Created using AbitMORE ® SCM Reporting 3.1.0 www.AbitMORE-scm.com
**************************** Bottom of Data *****************************

The only thing that's left (related to the remaining 18 JCLs that are still in checkout status) is reviewing/correcting/extending some of the ChangeMan ZMF housekeeping jobs (e.g. anything related to backups of CMNCMPNT has to be replaced by the 7.1 linear data sets replacements).

In another blog entry I plan to go in AbitMORE (oeps) details about how to interpret the above statistics (as compared to where we started from). Even though the above statistics do not reveal it, we did quite a lot of cleanups inside quite a few of skeletons, while we also introduced some new skeletons that fit into what I have started to call Object Oriented skeleton coding applied to ChangeMan ZMF customizations. That's another topic I plan writing some blog entry about, e.g. how you can see part of these techniques show up in some of the new (vendor versions) of ChangeMan ZMF skeletons (seems like some ChangeMan ZMF developers have been learning from us about what we already do for over a decade or so in many of the ChangeMan ZMF implementations we were involved in ...).