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.
ASR1 - AbitMORE® SCM Reporting > Rpt Info > Fields-short Row 1 to 14 of 14
Command ===> Scroll ===> CSR
3. Field Information:
Press ENTER to continue or END to return to the menu.
Field connector: AND Remove duplicates: YES
Column name Size Oper Value Ord Group
----------------- ---- ---- ------------------------------- --- -----
- APPL ID 0004 EQ #RPTV_APPL
APPL-PKGID 0010
Sta 0003 NI BAS,DEL
CMPNAME 0008 LK #RPTV_CMP_MBRNAME A
LTP 0003 NE #RPTV_CMP_LTP
- Like Type 0003 NE LOD
UPD DATE 0010 A
UPD TIME 0008 A
CMP STAT 0008
Dept 0004
Wrk Rqst Id 0012
Creator 0008
CMP HASH (STG) 0016
CMP HASH (CKO) 0016
******************************* Bottom of data ********************************
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.
ASR1 - AbitMORE® SCM Reporting > Generate report --------------------------
Command ===>
Report: Id ==> CMPVRSNS Desc ==> Component versions report
Input: Primary CMN ==> Y (Y=Yes,N=No)
Archive CMN ==> N (Y=Yes,N=No)
History CMN ==> N (Y=Yes,N=No)
External vars ==> Y (Y=Yes,N=No) Edit vars ==> P (I=ISPF,P=Panel,N=No)
Basket In DSN ==>
Output: Format ==> B (R=Report,B=Basket) Edit Fmt ==> Y (Y=Yes,N=No)
Details ==> Y (Y=Yes,N=No) Edit JCL ==> N (Y=Yes,N=No)
--------------------------------- Report vars ---------------------------------
| ASR1 |
| Command ===> |
| |
| Application Id ===> ABM (3 or 4 chars) |
| |
| Membername ===> %ABM* (8 chars) |
| |
| Library type ===> XYZ (3 chars) |
| |
| Press ENTER to process or END to return to previous menu. |
-------------------------------------------------------------------------------
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"):
SDSF OUTPUT DISPLAY BG03143A JOB09976 DSID 2 LINE 0 COLUMNS 02- 81
COMMAND INPUT ===> SCROLL ===> CSR
********************************* TOP OF DATA **********************************
J E S 2 J O B L O G -- S Y S T E M S 2 B 1 -- N O D E
18.03.33 JOB09976 ---- TUESDAY, 13 FEB 2024 ----
18.03.33 JOB09976 IRR010I USERID ABM03143 IS ASSIGNED TO THIS JOB.
18.03.33 JOB09976 ICH70001I ABM03143 LAST ACCESS AT 16:08:28 ON TUESDAY, FEBRUA
18.03.33 JOB09976 $HASP373 ABM03143A STARTED - WLM INIT - SRVCLASS BJOBLOW - S
18.03.33 JOB09976 IEF403I ABM03143A - STARTED - TIME=18.03.33
18.03.33 JOB09976 - --TIMINGS (MINS.)--
18.03.33 JOB09976 -JOBNAME STEPNAME PROCSTEP RC EXCP CPU SRB CLOCK
18.03.33 JOB09976 -ABM03143A CMPVRSNS 00 42 .00 .00 .00
18.03.53 JOB09976 -ABM03143A EXTRACTP 00 32639 .02 .00 .32
18.03.53 JOB09976 -ABM03143A PRTSORTP 00 22 .00 .00 .00
18.03.55 JOB09976 -ABM03143A RPTCREAT 00 14706 .00 .00 .04
18.03.56 JOB09976 -ABM03143A RFRMTBSK 00 539 .00 .00 .00
18.04.00 JOB09976 -ABM03143A CPY2SRD 00 4572 .03 .00 .07
18.04.05 JOB09976 -ABM03143A SENDMAIL 00 1898 .01 .00 .07
18.04.05 JOB09976 IEF404I ABM03143A - ENDED - TIME=18.04.05
18.04.05 JOB09976 -ABM03143A ENDED. NAME-ASR 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.
