This article explains how to improve your company’s production JCL by creating and implementing a “production checklist.” The process, which can work miracles, consists of assessing your production JCL environment and taking corrective action using the checklist created during the assessment. JCL Production Checklist Defined A JCL production checklist simply lists items in your IT environment that need to be improved. The checklist will:  

  • Make JCL easier to update and use  
  • Reduce the time it takes to restart a production job  
  • Help new employees become more productive in less time  
  • Help employees understand good JCL code vs. bad code  
  • Stop poor coding habits from spreading  
  • Take advantage of system enhancements  
  • Provide JCL code upgrades to reduce run-time  
  • Eliminate misuse of resources such as people, tape, and DASD.  

The checklist is created to get results. Several specific problems with their solutions are detailed here, along with a sample JCL production checklist to address these problems. Also included are guidelines on how to create and implement a checklist for your environment.  

Learning From Others

The following stories come from participants in JCL training. They reviewed actual customer production JCL and applied what they learned to the customers’ JCL environment. They created a JCL production checklist for their environment.  

Problem 1: Every day when running the production batch jobs, the operators had to move production reports manually from the Held queue to the Output queue to print. On several occasions, production reports were accidentally deleted. Solution:The operations group established a standard for report processing, communicated the standard, and then enforced the standard. This resulted in zero loss of reports due to manual deletion (see Figure 1).

Problem 2: Block sizes coded on output DASD files for an entire application were high, but incorrect for the device type. Even though the block size was high, the size was inefficient because half of each track wasn’t being used. So, half the DASD for an entire application, with a large amount of data, was being wasted.  

Solution: The group established a standard for blocking, and communicated and enforced the standard, resulting in a significant gain in DASD resources (see Figure 2).  

Problem 3: While running batch production jobs, a job abended in STEP0180. Programming examined this job for several hours, focusing on STEP0180 before realizing the real problem was in STEP0090 (eight steps before STEP0180). STEP0090 executed with a return code of 8. There were no condition checks on the individual job steps, so the job continued to run when it should have been stopped at STEP0090 with the proper condition checks.  

Solution: The group coded condition checks for each step so they don’t waste time resolving abends (see Figure 3).

2 Pages