Your JCL will change over its life cycle. The dynamic of the modern enterprise require new functionality and adaptability in order to effectively support the batch environment. Adding a new job, changing existing PROCs, renaming or resizing datasets and adding a new database object, are some examples of the critical tasks that Production Control face every day. The challenge is to create methods and best practices that help manage those changes, in order to avoid costly delays and production job failures of mission-critical applications.
Change Impact Analysis is the process of analytically researching the potential impact of changes before they are made, and following a well-established set of validation/approval procedures. For example, if you are changing a Cataloged procedure (PROC), you must find out every JOB that calls the PROC, create a validation/run-time simulation batch stream, identify potential defects and take the necessary remedial actions before the change is promoted into the production environment.
Here are some steps you should follow to proactively manage changes:
- Define the change
- Trace every Job affected.
- Analyze the impact of the change.
- Implement the change.
Define the change
Take the time to clearly define the proposed change. Be very specific. Are you changing a single attribute on a DD statement? Are you adding a new Step? Will this change be made within a PROC or INCLUDE member?
Trace every Job affected.
Locate every Job affected. If you are changing the Job JCL member, only one Job will be affected. However, if the change will be made within a PROC or INCLUDE member, you will need to find out how many Jobs will be affected. How can you be certain you have found every, JOB, PROC, or INCLUDE which referenced a data set?, and what if a PROC uses a symbolics?
This task will require you to look through hardcopy listings, which could end up reading through thousands of pages, or performing ISPF 3.14 “Search-For Utility” searches (search through each Production Job, PROC, and INCLUDE Library). However, if a PROC uses a symbolic (i.e. PROD.SEA1.&LC1..DATA), ISPF 3.14 searches will not find this reference.
Analyze the impact of the change.
XREFplus+DBr is a powerful tool that enables you to comprehensively determine how your batch Jobs are using datasets, Jobs, Procs, programs, DB2 info, and scheduling components. Not only does it give you a complete picture of the correlations of your JCL, programs, and datasets, but the open database architecture allows you to integrate the collected data with other products (e.g. Change management Software such as ChangeMan, SCLM or Endevor).
This product can also resolve all symbolics, expand all PROCs and INCLUDEs, then generate cross-reference reports, which list “Where-Used” information for JCL “entities” such as PROCs, programs, and data sets. The result is a report that can identify the exact information that you need, and also the changes can be automated via an intelligent change options of the JCL Asset Management product JCLplus+.
Implement the change
Implement the plan developed and documented in the previous step. This will include:
- Check-out the Programs and JCL from the Production Libraries.
- Make changes to the existing program(s)
- Create a conversion program that will preserve existing data.
- Make changes to the Jobs, PROCs, and INCLUDE files to support the changed program.
- Validate and run-time simulate the affected Jobs with SEA JCLplus+. This product will expand the Job to include Cataloged PROCs and INCLUDE data sets.
- Validate and run-time simulate JOBs execution order or application (if applicable)
- Validate and run-time simulate using PROD (target) environment resources (if applicable)
- Validate and enforce Company’s JOB Standards
- Validate and run-time simulate JOB Scheduling variable resolution
- Promoting the updated Programs and JCL into the Production Libraries.
It’s very important to be considered implementing a process to review the JCL from an Optimization perspective, during the change course. For example: are the parameters specified within the Job optimized? Particular attention should be paid to REGION, BLKSIZE, and SPACE allocations and others.
“Best Practices” for Production JCL change requires a change impact analysis process. This means that you need to locate every component that will be affected by the proposed change, analyze how that change will affect each Job, implement the change, then validate and run-time simulate newly changed JCL for every Job prior to promotion into the Production JCL Environment.
In most z/OS environments, production JCL utilizes cataloged procedures for efficiency. This allows maintenance to be done in only one place (the single cataloged procedure), yet be effective for possibly tens or hundreds of Jobs that execute that PROC. This raises a difficult issue for validation, especially during the promotion process. The “best practices” approach dictates that when the modified PROC is being returned to production, EVERY Job that executes that PROC must be validated to ensure that no errors were accidentally introduced in any instance. This means that the promotion process must recognize every Job that executes the PROC in question, and pass each Job to JCLpus+ for validation before moving the PROC to the production library.
Although Change Impact Analysis reports can be created/reviewed manually (looking through hardcopy listings, ISPF 3.14 “Search-For Utility” searches, etc.), the total volume of information makes it a necessity to automate. Reports generated by the SEA Enterprise JCL Documentation and Cross-Reference Software, XREFplus+ DBr coupled with SEA JCL asset management software JCLplus, offers unlimited options to pinpoint and automate changes, lowering the cost and minimizing expensive production JOB failures.