August 8, 2017 | IBM Z

JCL Defects/Usage Metrics for Mainframe DevOps

image

JCL Defects/Usage Metrics for Mainframe DevOps

Today’s business climate demands that the mainframe IT environments accelerate batch component turnaround times to comply with lean and agile principles that enable organizations to more quickly seize market opportunities. To accomplish this, the importance of architecting a framework to manage the JCL asset and adopting flexible best practices to minimize JCL production defects cannot be overstated.

 

The models to automate and manage the JCL changes vary and depend on the organization objectives and delivery needs. The effectiveness of this model will determine the quality of the Job and, consequently, the reduction of production failures and defects. Regardless of the implemented model, the JCL validation and standards enforcement should be integrated into an automated source control promotion process (SCM), requiring the JCL member to be defect-free before it will be promoted from the “Test” into the “Production” Library.

 

The main advantages of this integration are: 1) the detection of defects when promoting a JCL change and, 2) the elimination of manual intervention by automating the promotion process. Unfortunately, an effective metrics gathering process is often overlooked. Tracking Job failures and understanding the reasons for those failures is an important step in reducing defects. Common sense and management experience show us that quality and speed objectives are much more often attained by data centers that heavily rely on statistics and metrics for continuous improvement.

 

The definition and implementation of a measurement system to allow monitoring of the whole SCM process represents the starting point towards management by metrics. This process should rely on a variety of metrics and reports to identify the quality of JCL changes. This information typically results in improved overall production quality and accelerated resolution times for the application development teams.

 

The JCL Asset Management Software should be equipped with an engine that not only produces Summary defect reports but is capable of generating a record (preferably comma-separated CSV format) with significant information that can be easily imported by any RDBMS, spreadsheet or other reporting system. Software products like the JCLplus+ component of the Plus+Pack suite from Software Engineering of America (SEA) incorporate such metrics generation as a fundamental capability.

 

The first step is to produce global statistics on a regular basis. This big picture is a snapshot of the overall quality of the JCL change process and the problems captured by the rules defined in the JCL Asset Management tool.

 

This set of metrics can help to determine a course of action to identify categories and priorities of repetitive problems that may impact the time to delivery of JCL components. These rates can also serve as a baseline for benchmarking purposes and validate the proper adoption of Best Practices procedures. These reports can also be broken down by failure type and by promotion stage within the SCM.

 

The modern organization’s dynamics, priorities and lack of resources also put the remediation of JCL on a lower priority scale. It is well known in the z/OS world that you seldom find somebody who writes new JCL. Developers basically copy existing JCL and modify it to meet their needs. This practice, however, just propagates the ‘old’ JCL’s bad coding practices and obsolete standards forward, challenging the process of identification and resolution of Job failures (Mean Time to Repair).

 

Armed with detailed Validation/Simulation metrics, organizations could more easily put into action practical and low cost actions to attack the ‘low-hanging fruit’, and cleanup recurring JCL defects and other root causes for problems. The goal should be toward delivery of high-quality JCL elements.

 

The detailed defects/standards process report is the base to identify not only JCL preventable defects but coding practices that could affect a Job’s performance. For example, Sort no longer requires allocation of SORTWK DD statements. Where it was once customary to add many SORTWK DD’s to prevent space Abends, now the SORT program allocates as much space as it needs dynamically.  Allowing the SORT program to dynamically allocate these SORTWK DD’s is faster and eliminates unnecessary allocation, improving runtime and reducing resource usage.

 Summary

The JCL Asset Management practice requires a comprehensive measurement system to establish a Management by Metrics practice that will assist Production, Infrastructure and Development areas in the resolution of JCL defects and keep them on a course of continuous improvement toward an efficient DevOps defects-free environment.