Abstract:
A software testing system for generating a test job control language (JCL) file is provided. The system includes a processor, a memory device for storing a source JCL file containing jobs and an instruction file containing instructions for modifying the source JCL file according to a test environment. A JCL generation module executed by the processor determines all procedures that are referenced by the jobs in the source JCL file, opens each unique procedure of the determined procedures once and modifies the jobs in the source JCL file based on the instruction file and the opened procedures to generate the test JCL file. By opening each procedure only once which may be called multiple times in the jobs, the JCL generation module substantially increases the speed of generating the test JCL file.

Description:
FIELD OF THE INVENTION 
     The present invention relates to generating jobs in a computing environment, and more particularly a system and method for generating test job control language (JCL) files in test bed computing environments. 
     BACKGROUND OF THE INVENTION 
     Making modifications or enhancements to software running in a live computer system requires careful testing and deployment, especially if the system is a large transaction processing system such as VisaNet™, which processes over one hundred million financial transactions (e.g., credit card transactions) per day. Typically, a set of software modification projects are initially tested in a test environment which emulates the actual transaction processing system. 
     The test environment is typically simulated on a mainframe computer system using program instructions and parameters encoded in JCL (Job Control Language). In JCL, a program unit for executing a particular task is referred to as a ‘job’. A job may reference and call various procedures (procs) which perform specific operations and the procs call executable modules or programs. A number of jobs are generally executed in a sequence to test a scenario in the test environment. 
     As shown in  FIG. 1 , one known system  10  in the prior art employs a JCL offline test tool (JOTT)  12  which generates an output JCL file  14  including one or more jobs for use in a test environment. The program JOTT  12  is discussed more fully in U.S. Pat. No. 6,430,708, issued on Aug. 6, 2002, which is incorporated herein by reference. The output JCL file  14  is generated based on an input source JCL file  16  and an environment code file (‘script’)  18 . The environment script  18  is used to configure the environment in which the output JCL  14  operates. The environment script  18  includes lines of code that specify variables for which values are not yet set, and overrides which change the names of certain variables. A portion of an exemplary source JCL is shown in  FIG. 8 . The portion of the source JCL file shown includes, among other items, a job reference (first line), associated variables  803 , a procedure library reference  804 , and a procedure call  806  including associated variables  807 . 
     In addition to generating the output JCL file  14 , JOTT  12  also generates support files  20  such as an environment test parameters file  22  that specifies operating parameters of the environment, a FLOW file  24  which lists jobs generated in an order in which they should be submitted for execution in the environment, a JCLLIST file  26  which lists environment details such as various overrides and jobname overlays for changing job names, a JCLOVER file  28  with a collection of most of the specific override instructions pertaining to the JCL  14 , a NOTES file  30  for listing text notes such as error messages, a VALIDATE file  32  listing a date of validation of the JCL  14 , and a HOTLIST file  34  listing a collection of specific override instructions such as dataset name overrides. 
     In such prior art systems, the numerous support files  22 - 34  do not provide any clear definition of where global changes have been made in generating the output JCLs  14  based on a specific environment script file  18 . That is, a library of different source JCLs  16  may be the basis of a library of output JCLs  14  adapted to a specific environment, and global changes, such as overrides, may be applied to entire source library  16  to generate a library of output JCLs  14 . Although the support files  20 - 34  may indicate specific overrides, none of the support files  20 - 34  in the prior art provide a clear indication of global overrides spanning the library of source JCLs  14  in a common JCL library for an environment. 
     It would be desirable for a JCL generating module to indicate global aspects of JCLs generated and operating in a common environment. 
     In addition, such prior art systems including JOTT  12  utilize expensive and complex utilities, which hinder effective generation of output JCLs  14  in test environments. For example, in the prior art systems  10  using JOTT  12 , the generation of the output JCL  14  is performed inefficiently, as follows. 
     In the process of generating output JCL file  14 , the system  10  operates according to the method shown in  FIG. 2 , in which JOTT  12  receives the input files  16 , 18  in step  36 , opens the source JCL file  16  in step  38 , and determines in step  40  an initial job listed in the source JCL file  16  to be a current job to process. Each source JCL file  16  lists one or more procs to be called and performed on a line-by-line basis. 
     The prior art method (of  FIG. 2 ) opens a first proc called by the current job in the source JCL file in step  42 , with the first proc as the current proc to process. In “opening” the proc, the prior art system reads and determines the source proc, such as the library and path for accessing the proc. The step of opening a procedure or proc involves opening a new variable for the output JCL file  14  which is to be named and loaded with data, such as a proc name to be used by the output JCL  14  in the environment. JOTT  12  then applies changes to the current proc in the current job in step  44  based on the input files, such as the environment script file  18 , by filling in the opened variable. The method then determines in step  46  if all of the procs in the current job have been processed. If not, the method then finds the next unprocessed proc in the current job in step  48  to process, and loops back to perform steps  44 - 46  to iteratively process every single proc until all procs in the current job have been processed in step  46 . 
     The method then proceeds to step  50  to close the processed procs in the current job, for example, by saving the record of the variables or modified procs being generated in the output JCL  14 . In step  52  it is determined if all of the jobs in the source JCL  16  file have been processed. If not, the method finds a next job in the source JCL  16  in step  54  to be the next current job to process, and loops back to perform steps  42 - 52  to iteratively process every single job and every single proc, until all procs in all of the jobs of the source JCL  16  have been processed in step  46 . 
     In the above described method, procs processed in an earlier job may be identical to procs processed in a later job, and the same procs are reopened every time they are encountered in a current job. New variables and new values are repeatedly generated for each proc until the final output JCL is generated in step  56 , regardless of earlier-performed operations. 
     Each time a proc is opened, there is an incremental processing time for the opening process. Although JOTT  12  and such test environments are operating on relatively fast computer systems, over any length of time, the incremental processing time involved in each opening process accumulates to become noticeable delays in processing which slows the generation of the output JCL file  14 . For projects implementing changes in hundreds or thousands of JCLs in multiple environments, such repeated opening and closing of procs result in significant delays in testing and implementing new software in test environments and, ultimately, delays full implementation in real-world environments, for example, in transaction processing systems. 
     It would therefore be desirable to avoid such delays, and provide an improved method and system for generating output test JCL files through greater efficiency in the processing of jobs and procs in JCL generation. 
     SUMMARY OF THE DISCLOSURE 
     According to one aspect, the present invention provides a system for generating a test job control language (JCL) file that comprises a processor, a memory device for storing a source JCL file containing a plurality of jobs and an instruction file. A JCL generation module executable by the processor is adapted to determine all procedures that are referenced by the plurality of jobs in the stored source JCL file, open each unique procedure of the determined procedures once and modify the plurality of jobs in the source JCL based on the instruction file and the opened procedures to generate the test JCL file. 
     According to another aspect, the present invention provides a method for generating a test job control language (JCL) file comprising: a) storing a source JCL file including a plurality of jobs and an instruction file containing instructions for modifying the source JCL file according to a test environment, b) determining all procedures that are referenced by the plurality of jobs in the stored source JCL file, c) opening each unique procedure of the determined procedures once, and d) modifying the plurality of jobs in the source JCL based on the instructions in the instruction file and the opened procedures to generate the test JCL file. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates a system for generating JCLs in the prior art. 
         FIG. 2  illustrates a method for generating JCLs in the prior art using the system of  FIG. 1 . 
         FIG. 3  illustrates an exemplary computer-based system implementing the present invention. 
         FIG. 4  is a block diagram showing a system for generating a test JCL file according to an embodiment of the present invention. 
         FIG. 5  shows a portion of an example GLOBAL instruction file according to an embodiment of the present invention. 
         FIG. 6  shows a portion of an example SPECIFIC instruction file according to an embodiment of the present invention. 
         FIG. 7A  is a flow chart of a method of generating a test JCL file according to an embodiment of the present invention. 
         FIG. 7B  is a continuation of the flow chart of  FIG. 7A . 
         FIG. 8  shows a portion of an exemplary source JCL file according to an embodiment of the present invention. 
         FIG. 9  shows a portion of an output test JCL file generated according to the present invention. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     For purposes of this application, the terms “code”, “program”, “application”, “software code”, “software module”, “module” and “software program” are used interchangeably to mean software instructions that are executable by a processor. 
     An exemplary block diagram of a computer-based system  300  according to an embodiment of the present invention is shown in  FIG. 3 . Referring to  FIG. 3 , the computer-based system  300  includes a tester computer  302  having a display  304  and an input device  306 . The computer-based system  300  includes a CPU  308 , a communication device  310 , and a memory  312 , each of which is connected to a program storage unit  314  and a data storage unit  316 , via a bus  317 . The program storage unit  314  includes a JCL generation module  318  according to the present invention, as described herein. The computer-based system  300  may be a mainframe computer and/or a network of computing environments for interacting with the tester computer  302 , which may be a terminal of the mainframe computer or network. 
     The JCL generation module  318  of computer system  300  generates JCLs that are modified so as to meet the requirements of a particular testing scenario. For example, if a certain library of jobs LIB 1  was previously created or modified to meet the requirement of a first testing scenario, SCENARIO  1 , and a tester now wishes to test computer system according to another scenario, SCENARIO  2 , the JCLs in LIB 1  are modified according to the requirements of SCENARIO  2 . 
     The computer-based system  300  allows the tester to specify a script or global file to be processed by the computer-based system  300 . If the tester selects and specifies a script, the computer-based system  300  calls a program, referred to as ‘GENPARM’ which generates one or more instruction files  406  (shown in  FIG. 4 ). In the embodiment shown, GENPARM generates the following instruction files: GLOBAL file  410 , SPECIFIC file  412 , and FLOW file (not shown) similar to that in  FIG. 1 . GENPARM also generates environment&#39;s test parameters file (not shown) similar to that in  FIG. 1 . These instruction files  406  are generated based on testing information (e.g., a script file) such that the instruction files are configured to enable a particular testing scenario. 
     Referring now to  FIG. 4 , which shows a system  400  for generating test JCLs according to the present invention, a source JCL file  402 , a source proc file  404  and the instruction files  406  are input to JCL generation module  318 . The source JCL file  402  contains the JCLs that are used or that will be used in a live production system which are to be modified according to the requirements of a test scenario, and source proc file  404  includes a library of procs accessible by the jobs of source JCL file  402 . The instruction files  406  include instructions for modifying source JCL file  402  into an output test JCL file  408  configured for a particular test scenario. In the embodiment shown, as discussed earlier, the instruction files  406  include a GLOBAL file  410  and a SPECIFIC file  412 . GLOBAL file  410  includes modifications, such as reference changes (overrides), which apply to all of the jobs and/or data sets in the source JCL file  402 . 
     A portion of an example GLOBAL file  410  is shown in  FIG. 5 . One example instruction of GLOBAL file  410  shown in  FIG. 5  is an ‘override’ instruction used to replace a reference (e.g., a file name) with a substitute reference. In particular, instruction  502  is a FOR:USE instruction which replaces every instance of data set name:“TBR.PROD.CF.CONFIG.OFFLINE” throughout the source JCL file  402  with data set name “DBA.TREG.CF.CNFG.ONLINE.D070724”. By changing name references, different files may be accessed that contain data and instructions appropriate for the selected test scenario. The GLOBAL file  410  also includes a list of all jobs (not shown) contained in the source JCL file  402 . 
     SPECIFIC file  412  includes modifications for one selected job of the source JCL file  402 . A member of an example SPECIFIC file  412  is shown in  FIG. 6 . The member  602  includes instructions pertaining to a particular job. Other members of SPECIFIC file  412  (not shown) pertain to other jobs of source JCL file  402 . In the example shown, instructions  604  and  606  are data definition override (DDOV) instructions pertaining to a proc named ‘PBR’. Instruction  604  is used to delete a definition of a data set name “DPA.TREG.JOTT.TESTPARM.BRP(&amp;DELPARM)” included in proc PBR while the following instruction  606  defines a data set name “DPA.TREG.JOTT.TESTPARM.BRP(&amp;DEFPARM)”. When GLOBAL file  410  and SPECIFIC file  412  have conflicting instructions that apply to the same JCL code of source JCL file  401 , the instructions in SPECIFIC file  412  supersede or override the instructions in GLOBAL file  410  for the jobs to which they apply. Additionally, if SPECIFIC file  412  includes a member corresponding to a particular job in source JCL file  402 , the member may include a reference to the JCL library where the source JCL file is located. Otherwise, if SPECIFIC file  412  does not include a member corresponding to a particular job, the JCL library reference from the GLOBAL file  410  is instead used for the job. 
     Referring now to  FIG. 7A , a flow chart of a method  700  of generating a test job control language (JCL) file according to an embodiment of the present invention is shown. The following steps are performed by the JCL generation module  318  unless otherwise stated. In step  702 , the method begins. In step  704 , the instruction file  406  is read into memory. In embodiments in which the instruction file  406  includes a GLOBAL file  410  and a SPECIFIC file  412 , both files  410 ,  412  are read into memory in step  704 . In the following step  706 , a job counter (M) which is used to iterate through the list of jobs in GLOBAL file  410  is initially set to one (1). In step  708 , it is determined whether SPECIFIC file  412  includes a member corresponding to the Mth job listed in GLOBAL file  410 ; If so, in step  710  the location of the source JCL of the Mth job is determined from a reference in the SPECIFIC file  412 , and the located job is then copied into a file in step  712 , e.g., a flat, unformatted file, referred to herein as the J-file, which is an intermediate file that will be converted later to the test JCL; if SPECIFIC file  412  does not include a member corresponding to the Mth job, in step  714  the location of the source JCL of the Mth job is determined from a reference in GLOBAL file  410  and the job is then copied into the J-file in step  716 . 
     After either of steps  712  and  716 , it is determined whether the Mth job is the last job listed in GLOBAL file  410  in step  718 . If not, counter M is incremented in step  720  and the method cycles back to step  708 . If it is determined that the Mth job is the last job, the method continues in step  722  (shown in  FIG. 7B ). When step  722  has been reached, all of the JCL code of the jobs listed in GLOBAL file  410  has been copied into the J-file. Turning now to  FIG. 7B , in step  723 , a counter (N) is initialized to one (1). In the following step  724 , the Nth job listed in the flat file is read, and in step  725  all of the procs listed in the Nth job are opened. In step  726 , the opened procs are copied onto another file referred to herein as the P-file. The P-file may also be a flat, unformatted file. If the procs listed in the Nth job are already opened in the P-file, they are not opened again. It is determined in step  727  whether the last job in the J-file has been read; if not, the counter (N) is incremented in step  728  and the method cycles back to step  720 ; if so, then all of the procs from all the jobs in the J-file  406  have been opened and copied into the P-file. In step  730 , the source JCL procs are closed. In this manner, all of the procs are opened only once in one execution thread and then closed, which greatly reduces the processing time for generating the output JCL file  408 . 
     Thereafter, in step  732 , the instructions in GLOBAL file  410  are applied to all of the jobs in the J-file using any references required from the procs in the P-file which is efficient to access and scan, and in the following step  734 , instructions in SPECIFIC file  412  are applied to selected ones of the jobs in the J-file, again using any references required from the procs in the P-file. The application of instructions from GLOBAL and SPECIFIC files  410 ,  412  updates references and/or data sets and thereby modifies the JCL code in the J-file. In step  736 , the J-file is converted into a test JCL file  408  configured for a particular test scenario. The method ends in step  738 . 
     A portion of test JCL file  408  modified based on the source JCL file  402  shown in  FIG. 8  is listed in  FIG. 9 . A comparison of the exemplary source JCL file  402  shown in  FIG. 8  and the output JCL file  408  shown in  FIG. 9  illustrates how the source JCL file  402  has been modified using the JCL generation module  318  as described above. For example, referring to  FIG. 8 , in the source JCL file  402 , a set of parameters  803  includes a CLASS parameter which is set to “R”, while in the corresponding parameters  903  of test JCL file  408 , the parameter CLASS parameter is set to “J”, which indicates that certain messages are to be transmitted. Similarly, in the source file  402 , the procedure call  806  to procedure ‘PADCOLD’ has associated parameters  807  including TYPE=WARM, VIC=EA, and SYSTEM=PASYSTEM. In contrast, the output JCL file  408  in  FIG. 9  includes a procedure call  906  to the same procedure PADCOLD but in which the parameters  907  have changed. For example, TYPE remains WARM, but the parameters VIC and SYSTEM have been changed to VIC=OV and SYSTEM=PBREGQA. The changes between the source JCL file  402  and the test JCL  408  are made to reflect changes in the test environment. 
     As noted above, one of the main advantages of the present invention is that procs are opened (loaded from memory) only once, rather than each time the procs are encountered. The information within the procs is accessed instead from a single flat file and loaded to memory, which takes much less processing time to read. An additional advantageous aspect of the present invention is that, by delineating global and specific modifications via the GLOBAL and SPECIFIC files  410 ,  412 , further updates of the output JCL file  408  at a later date may be simpler to perform by reviewing, for example, the global overrides in the GLOBAL file  82  which, in the prior art, either could not be performed or was confusing at best. 
     The foregoing specific embodiments represent just some of the ways of practicing the present invention. Many other embodiments are possible within the spirit of the invention. Accordingly, the scope of the invention is not limited to the foregoing specification, but instead is given by the appended claims along with their full range of equivalents.