Component versions report for any DFZ pkg
As someone experienced in ChangeMan ZMF administration, you're likely aware that over a period of fifteen years, a ChangeMan ZMF environment accumulates a significant amount of inactive packages, lingering without completion, with no one accountable for their status. These packages occupy disk space without purpose. How can we efficiently locate and tidy up these dormant packages?
Our solution
We've been focused on tidying up different DFZ packages. Here's one of the reports—a CSV generated using ASR—detailing the components we've targeted:
To identify these components, we employed several queries, akin to sophisticated SQL queries.
To define the report variables (those beginning with a #-sign in the screen above), we provided specific (blue) values via a popup panel displayed prior to submitting the ASR job.
We'll leave you to explore the various data points in the CSV file. However, here are a few highlights to consider:
The prevalence of duplicates across various packages, indicated by identical values for column CMP HASH (STG).
The package components which are identical to their baseline 0 version, sharing the same value for CMP HASH (STG) and CMP HASH (CKO).
The presence of numerous parallel versions of the same components in DFZ packages.
Components remaining in CKO status for extended periods.
Additional notes regarding ASR:
Creating this report (CSV) required no knowledge of XML services or programming languages such as REXX or COBOL. We simply entered our entire set of design specifications for the report on panels similar to those above. These specifications were then saved in an RPTD member, which was utilized in the actual ASR job to generate the requested CSV report. This setup also allows for modifications to the design specifications post-generation, including sorting, selection criteria, output columns, etc.
The actual ASR job (to generate the report output in CSV format) completed in just 32 seconds elapsed. Here are some of its job statistics (notably, "TOTAL CPU TIME=.08 TOTAL ELAPSED TIME=.52"):
This report is typically one that you may need to run multiple times over a period of weeks, months, or periodically, by anyone authorized to do so, without altering the design specifications like selection criteria. Therefore, we could consider two options:
Publishing it via ASR's "Report catalog", enabling any ChangeMan ZMF user to run it on demand, with the ability to input desired runtime values for the report variables using the provided popup panel.
Saving the JCL of the job that generated the report (CSV) and scheduling it as a periodic (ChangeMan ZMF housekeeping?) job.
It would be intriguing to see someone create a similar report using any programming technique they prefer, such as utilizing XML services combined with SERXMLRC, SERXMLCC, or SERXMLBC. Then, we could explore answers to the following questions:
What skill set is required to develop such reports, and when would a skilled developer be available to undertake coding?
How much time (hours, days, or weeks) would be needed to develop such reports, if technically feasible?
What would be the duration and CPU resource consumption of the reporting job? Considering we have around 17,500 packages to be reported, with a potentially vast number of component history records.
How easy would it be to refine or adapt selection criteria during development, and how to facilitate end-user changes for various runs of the report?
How straightforward would it be to use the report and then clone it for other reporting needs? For reference, we managed to clone a sample report delivered with ASR and refine its criteria in about 15 to 30 minutes.
We subsequently communicated with the development team:
Assisting in deciphering the real data within the CSV report and outlining related questions for the development team.
Exploring how to reuse the same report design for the other development teams.
Identifying cleanup actions to initiate and determining which decisions from the development team are necessary for specific data.
Considering other report variations, such as determining a cut-off date to spread cleanup efforts over several weeks or months, avoiding extended ChangeMan ZMF housekeeping runs.
Contact us today to find out how to reproduce this case in your environment!
Discover More Ways to Leverage SCM Reporting
