Audit Serve, Inc.

The Worldwide Connection for Audit, Security, Control and SOX Professionals

The Control Impact of the JES2 Concatenation

By: Mitchell H. Levine, CISA
Audit Serve, Inc.

                                                             

Low Cost & Highly Skilled 
IT Audit and SOX Consulting Resources Available Immediately
Call Mitch Levine at (203) 972-3567 or 
email levinemh@auditserve.com for additional information

In order to reduce the number of JCL statements contained within a JCL member, catalog procedures (PROCS) are used to store common JCL statements. The use of catalog procedures are used in the production batch processing environment.

How JES2 Fetches PROC

In order for JES2 to determine the location of PROCS, it is stored in a set of procedure libraries (PROCLIBs) which are defined in the JES2 concatenation. The JES2 concatenation is defined in the JES2 startup procedure which is stored in SYS1.PROCLIB. PROCLIBs are organized in groupings which are referenced by the //Ddname. Execution JCL, which executes the PROC (i.e., except for Started Task Procedures), can instruct JES2 to search a specific PROCLIB grouping to retrieve the PROC. It does this by specifying /*JOBPARM P= in the execution JCL. If JOBPARM is not specified in the execution JCL, then the PROCLIB= statement within the JOBCLASS parameter (i.e., defined in JES2 initialization parameter file) of the JOBCLASS that a user submits from will identify the //Ddname within the JES2 startup procedure to search for the PROC.

Within each Ddname of the JES2 startup PROC, multiple PROCLIBs may be specified. When multiple PROCLIBs are specified in a Ddname, this is referred to as a dataset concatenation. JES2 will search the dataset concatenation for a specified PROC member based on the sequence in which the datasets are defined. The search through the dataset concatenation will stop once a specified PROC member is found.

Identifying Started Task PROCLIBs

Started Tasks (STC) are procedures started from the console which remain in its own address space. All MVS subsystems and most system software products (e.g., CICS, CA-7) are started as a STC (e.g., VTAM, TSO).

STC PROCS, like application PROCS, reside in PROCLIBs which are defined in the //PROCxx DD statement of the JES2 startup PROC. The STC PROCLIBs DDname are identified by the PROCLIB= parameterof the STCCLASS statement which is defined in the datasets (i.e., JES2 initialization parameter file) that are referenced by the //HASPPARM and //ALTPARM DD statements within the JES2 startup PROC.

By default, SYS1.PROCLIB (i.e., unless overridden in the MSTJCLxx PARMLIB member) is a STC PROCLIB, but other datasets can also be STC PROCLIBs. The PROCLIBs which are specified, are concatenated data sets which are searched when a STC is executed. If a STC member is specified in multiple PROCLIBs, the STC member which appears first in the data set concatenation will be executed.

There are many control exposures related to Started Tasks which will be discussed in a future article.

Exposures Relating to the Execution of the Incorrect PROC

PROCS are not only used for production batch processing, but also to test batch programs which are developed and to perform various system functions such as compiling programs. Therefore, PROCS should be segregated into PROCLIBs according to the functions they perform. Production and Started Task PROCLIBs should be maintained by the person in the change control process who is responsible for their migration to their respective PROCLIBs. PROCS used for program development and programmers’ system tests are maintained by the development group. Intermingling production, non-production, and Started Task PROCS in the same PROCLIB would present a major control exposure since update access would be required to be granted to multiple job functions.

During a compliance audit, the auditor should identify the various PROCLIBs defined in the JES2 startup PROC and verify that each PROCLIB is used for a specific function, Access to these PROCLIBs are properly segregated should also be reviewed to ensure that they are restricted to the appropriate individuals.

Assuming that the PROCLIBs are properly segregated according to the functions they perform, the next control concern is to ensure that proper the PROC member is retrieved by the execution JCL.

As previously mentioned, the execution JCL can limit the PROCLIBs to be searched for a specific PROC by defining a/* JOBPARM P= statement in the execution JCL. This step would limit the search of PROCLIBs to the datasets defined within the specified JES2 Ddname. However, the order in which the PROCLIBs are specified within the Ddname will be the order in which JES2 will search for a specified PROC. Therefore, if a production job has a /* JOBPARM statement which refers to the JES2 Ddname having a development PROCLIB as the first dataset in the concatenation, and the PROC name being searched is present in the development PROCLIB, then the wrong version of the PROC would be executed. This example highlights two alternatives for the organization of the JES2 PROCLIB concatenation.

First, a determination should be made of whether a unique naming convention will be used for PROCS as the basis for retrieving a PROC from the appropriate PROCLIB.

Secondly, how will PROCLIBs be organized in DDname groupings? Will specific Ddnames be assigned to specific processing functions (e.g., production, testing, development), whereby PROCLIBs used for other processing functions will not be present in a Ddname grouping of PROCLIBs? A variation to this approach would be to assign a DDname grouping to a specific processing function but allow a Ddname grouping of PROCLIBs to include PROCLIBs for other processing functions. To ensure that the appropriate PROC is retrieved, the PROCLIB is associated with required processing function should be defined as the first PROCLIB in the Ddname’s dataset concatenation. This second approach would not rely on a unique naming convention for the PROC to retrieve the appropriate PROC, but rely on the execution JCL to specify the appropriate DDname.

Regardless of the approach used, there is no automated control to ensure that the JOBPARM statement is coded, the correct Ddname is specified in the JOBPARM statement, PROCLIBs are defined for each processing functions, and that the same PROC is not specified in multiple PROCLIBs within a dataset concatenation.

This is reason that the auditor should perform a compliance test to ensure that these manual controls are adhered to. If naming conventions is the basis for retrieving the correct PROC, then each of the PROCLIBs associated with every Ddname grouping should be reviewed to ensure that they all contain unique PROCS. If JOBPARM statements are not used for the production execution JCL, then the review can be limited to the PROCLIBs specified in the //PROCxx of the JOBCLASSes that users submit their jobs from (i.e., review PROCLIB=statement for all JOBCLASS parameters defined in JES2 initialization parameter file in order to determine the //PROCxx). If JOBPARM statements are used by production execution JCL as the basis for searching a specific JES2 DDname, then the production execution JCL should be reviewed to ensure that they specify the correct DDname. Similarly, the DDname within the JES2 PROC should be reviewed to ensure that the production PROCLIB is the first PROCLIB in the dataset concatenation.

The exposure of executing the wrong PROC is limited to the PROCS issued by production execution JCL. If a PROC which is contained in a production PROCLIB is executed by a test job (JCL), then an attempt would be made by the job to update production datasets. However, the job should abend assuming that the user submitting the job does not have update access to production datasets. If a non-production PROC is being executed by a production job (i.e., execution JCL), then the program would be retrieved from a non-production library 9i.e., potentially unsecured library) which could possibly have production datasets defined in the PROC. This situation can potentially occur when a new PROC is migrated from the test to production environment and the dataset where the program resides has not been changed from that which was used in the test environment (note: See JESEXIT6 article for controls which could be used to prevent production programs from being retrieved from non-production load libraries).

MVS/ESA Version 4.2 Changes to Retrieving Procedures

MVS/ESA version 4.2 introduced the JCLLIB statement which may be used in execution JCL to define the specific PROCLIB from which to retrieve a particular PROC. This new feature provides an effective control to ensure that the production jobs (i.e., execution JCL) are only retrieving production PROCS.

The compliance test in this case would be to review the production jobs to ensure that they have the// JCLLIB ORDER= (‘‘) statement coded. This PROCLIB specified in the JCLLIB statement does not require the PROCLIB to be specified in the JES2 concatenation. Therefore, when performing a review for the PROCLIB specified for each of the production JCL members, you should verify that the access to these libraries are restricted to the appropriate individuals. In addition, multiple PROCLIBs can be defined in the JCLLIB statement. The order in which these PROCLIBs are searched is based on the order in which they appear in the ORDER= parameter. If multiple PROCLIBs are being defined in the production execution JCL member, then these libraries should be reviewed to determine whether the same PROCS are defined in each of the libraries.

This article was written more than one year ago. Events 
may have changed since this article was written.

Copyright  2006, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing.

This article appeared in a past issue of the Audit Vision E-Mail Newsletter.

Technical Articles | Conferences | Audit Programs | Audit Serve Seminars | Consulting Services | Audit Vision Newsletter | What's New | Contact US

This website has been optimized for Netscape and Internet Explorer 4.0 and above.  Your comments and suggestions are always welcome, please email webmaster@auditserve.com.
Copyright © 2000  All rights reserved.  27 Pine Street, Suite 700, New Canaan, CT 06840 USA.