Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
1999-04-16
2002-08-06
Ray, Gopal C. (Department: 2181)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C714S025000
Reexamination Certificate
active
06430708
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to computer software for testing programs in a large computing environment. More particularly, the invention relates to techniques for automatically generating a test environment that reflects changes or additions made to a production environment.
2. Discussion of Related Art
In complex batch-processing computing environments, typically performed on mainframe computers in large enterprises, testing and maintenance of programs that run in the “real-world” business environment, known as production, have to be performed frequently and reliably. For example, if one program is changed, each of the batch-processing jobs that call that program would likely have to be tested. Furthermore, each batch-processing job might have to be tested for many reasons including year 2000 compliance, user interface, and financial accuracy.
Errors or mishaps in production affecting actual business data can have serious technical ramifications which, more importantly, can lead to adverse business consequences. Not only do production programs and modules need to be tested often, but also because of the large and occasionally enormous processing load, management and maintenance of the testing environment is itself a significant task requiring much time and effort. Even with well-staffed testing and quality assurance teams at many organizations, the testing process is still error-prone, mainly because it is still manually intensive despite some degree of automation.
FIG. 1
is a block diagram comparing production and test environment components as is well known in the field of software testing in a batch processing environment. A production computer
100
has access to various production data storage areas containing various programs and data. The program and data of primary interest here are the production Job Control Language (JCL) programs, referred to as members,
102
and production data files
104
. JCL members
102
, also referred to as jobs, are programs that control the management of data files and the execution of programs, such as COBOL or DB2 programs, comprising the batch processing on the production computer. As is known in the art of computer programming, the JCL programming language, originally developed by the IBM Corporation, is used to control the flow of program execution in a batch processing environment, such as in IBM's MVS operating system. Batch processing in the MVS environment typically runs on mainframe computers and involve hundreds or thousands of batch programs. JCL members and batch processing are tools and techniques well known in the computer field, specifically the field of mainframe computing.
Production data files
104
are data files that contain actual data used in production, these files may be flagged as production files by, for example, beginning with the letter “P”. These data files can include, for example, database files containing production data. The letter “P” is also used to distinguish JCL members and other production-side data as production items. Updates to production data must only reflect actual business transactions. Also associated with production computer
100
are data storage areas for production “PROCs” or procedures
106
and production “PARMs”
108
. PROCs are essentially subroutines called by JCL members
102
. PARMs are used by JCL members and production programs (i.e., the actual data processing programs whose execution is controlled by the JCL members) to set runtime parameters.
A test environment includes a test computer
110
, typically another mainframe computer in the batch processing context. Test computer
110
also has various data storage areas that generally mirror data storage areas on the production side. One of the data storage areas contains test JCL members
112
and test data files
114
. The files can include control and historical files, as well as input files. The test data and programs in these storage areas may be distinguished from production data and programs, e.g., by placing an indicator such as the letter “T” at the beginning of each data file and program name. Another data storage area holds test PARMs
116
used by test JCL members that are somewhat different from production PARMs
108
. Because the test JCL members do not perform in exactly the same manner as the production JCL members, the test programs normally do not use production PARMs
108
. However, test JCL members
112
can use production PROCs
106
.
FIG. 2
is a flow diagram showing a process of manually creating a test environment from a production environment as is known in the art. At step
202
production JCL members
102
that are to be tested are copied from a controlled production library into a tester-controlled library (e.g., a tester's private library) or test group-shared library. Also copied are the production PROCs needed to test the JCL members. At step
204
changes and overrides are made to the copies of the production JCL members to reference the desired test environment. This typically involves changing library concatenations to suit the particular test being performed (e.g., ensuring that they point to appropriate test modules). The overrides are generally made to PROC parameters so that they reference the desired test environment. This step is manually intensive since it involves examining each PROC that is called by the JCL, determining which PROC parameters can be overridden in the JCL and editing those values. This needs to be done for each test run. It is generally an error-prone and time consuming process.
At step
206
the tester must examine the test JCL to check the input and output data files used by the test JCL. Proprietary tools can be used to scan the test JCL and provide a report of referenced files (referenced files can be hidden in the programs and thus are not easily detectable by a human tester). The tester may need to scan the report to make sure the test JCL members point to the right data files. The tester must also check for any other errors in the test JCL which typically involves manually scanning the JCL members. This step is also manually intensive and requires significant effort and attentiveness on the part of the tester to catch errors.
At step
208
the tester determines whether any corrections or overrides are needed for the test JCL after examining the programs at step
206
. If corrections or overrides are required, they are made at step
210
. At this step the tester generally builds any missing files needed by the test JCL and makes any overrides to the data sets. If no corrections or overrides are needed, the tester places the test JCL in a user-controlled library for execution on the test computer. The test JCL is now in condition to be used for the actual testing of the production JCL copied at step
202
. Up until this point, all the steps were needed simply to prepare the JCL members for actual testing.
In addition, there is presently no completely automatic process for keeping files and programs up to date (i.e., consistent with current programs and files that are being tested). This still has to be done manually by the tester. Once in the user-controlled library, testing the JCL will require access to a JCL or job scheduler which contains the flow or order in which the JCL members (of which there can be hundreds) will execute. Presently, there are no tools that can provide the tester with a visual representation of the job flow for the particular test being performed.
One attempt to automate the process of preparing test JCL involves using “skeleton” JCL members. These programs contain symbolics in place of actual variable names which are substituted with variables or other data during execution. The symbolics are programmatically converted to variables. Typically there are many skeletons of a JCL member or program where each skeleton can be used in a different test thereby enabling rapid population of test JCL members and allowing many tests using the same JCL member to run at the same
Beyer Weaver & Thomas LLP
Ray Gopal C.
Visa International Service Association
LandOfFree
Method and apparatus for testing job control language (JCL)... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for testing job control language (JCL)..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for testing job control language (JCL)... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2895933