The value of JCL standards is well known to those who of us who help companies and data centers operate more efficiently and cost-effectively. The issue that many companies face is that over the years, they have been involved in mergers, acquisitions, and data center consolidations. During these times, batch jobs from disparate data centers, each having their own standards, were eventually merged together. However, due to time constraints, and/or the lack of an automation tool like JCLplus+ from Software Engineering of America (SEA), the time required and risk incurred to merge the two sets of JCL naming conventions and other JCL standards was too great.
Consequently, the data center now has two or more separate sets of standards. We have all been involved in ‘we will clean that up later’ discussions, followed closely by ‘yes, but here are the current priorities!’
The result is a less efficient data center with a higher risk of production batch processing failure and it is an inhibitor to implementing effective DevOps methods for the mainframe environment.
Two of the key areas of inefficiencies include:
- Overhead – Maintaining multiple lists in the related tools, such as multiple sets of security rules and DASD pools. While this is often seen as simply the ‘new norm’ for levels of overhead to maintain the systems, it is extra overhead that could be reduced. In addition, when change is required, there are multiple places to address which decreases productivity and increases the risk of mistakes.
- Automation Disablers – Reduced ability to use automation: previous articles discussed, in detail, the power of standards to enable automation. For example, automatically converting Production JCL into Development JCL into Test JCL and back into Production JCL is exponentially harder when multiple sets of JCL standards are involved.
Data centers with multiple sets of JCL standards, (and/or inefficient or incomplete standards), are at an increased risk of Production batch application failures. One key area is security; when controlling access to Production data via security tools such as RACF, there is an increased risk of Production exposure when the security rules must account for multiple JCL naming conventions.
Few managers would argue with these stated benefits of implementing standards when starting with a ‘blank slate’ environment, but the real world presents exponentially greater challenges. For example, as mentioned above, it’s likely the case in many companies that due to mergers, acquisitions, technology changes, etc., over the years, there several different sets of standards in your production environment. To implement the single standard, management must weigh the above ‘possible’ benefits with the costs and risks associated with doing massive changes to a production batch environment that is likely running ‘OK’. To even begin to consider this, most managers will understandably require some quantifiable financial benefit and the best way to show this is with metrics!
The best approach is to get management agreement and business unit buy-in to standardize one or two of your production environments and identify measurable criteria for determining the resulting value of standardizing (e.g. defect prevention, release schedule acceleration, job throughput, etc.). You might also want to take into consideration the one-time cost of making the changes. Take a baseline measurement for a period before changes and then take the same measurements after the changes have been implemented. This should give you most of the quantifiable data you would need to prepare a justification to management for standardizing the remaining environments. By the way, SEA’s JCL Management product, JCLplus+, automatically captures the detail data to assist with much of this reporting. Additionally,
JCLplus+ is the leading tool in this space to automatically provide the information needed to perform assessment of your JCL standards and also to automate the actual changes needed to the JCL components.
