Testing COBOL applications on Z outside of their runtime environment

Author Regi Barosa

Overview

Testing  application programs as soon the developer make updates on them is the dream of most of our mainframe customers.

Can you imagine running  test cases once you compile and link one or more programs without having to deploy them to the environment that  they need to run?

The IBM Z Virtual Test Platform provides capabilities to shift left Application Integration Testing and execute tests using a test framework. We will cover some of these capabilities in this article.

What is IBM Z Virtual Test Platform (VTP)?

VTP is a product to be installed on z/OS  that allows your IBM Z developers to automate, and shift left the testing process of online transactions and batch programs early in the development lifecycle, without the need for artifacts to be deployed in the runtime target environments.

The developers will be able to execute the tests without the need for original middleware or data. Once the test use cases are recorded, you can execute the test without the need for original middleware (for example, CICS, IMS ) or data (for example Db2).
The tests could even be executed on a Z Development and Test Environment  (ZD&T) system running on-prem or on any cloud platform.

Also, developers can accelerate debug of issues raised in testing by easily recreating the scenario using a recording of the test that failed.

Testers could  use the recorded playback as part of regression testing strategy after compiler upgrades, Automatic Binary Optimizer (ABO) or Software Configuration Management (SCM) tool migrations.

Those recorded tests could  be part of a continuous integration and continuous delivery (CI/CD) pipeline using tools like  Jenkins or GitLab Ultimate for IBM z/OS.

Example used in this article

To show an example of using VTP we will use a simple COBOL/CICS/Db2 application that have 3270 screens.  But for sure it could work for any kind of environment, not just old “green screens”.  We could use modern interfaces like z/OS Connect and or RESTful CICS APIs.

In our example the developer received a mission to modify one existing COBOL program that accesses a Db2 table that is invoked by a CICS transaction.

Since he is concerned about introducing bugs while making changes he will use VTP to be sure that his changes will not break other programs. Note that IBM also has a technology named ZUnit that is designed to test one single program, that he could also use here.

Using VTP the developer will verify not just the program that he changed but also other programs used on the application.

Below is a part of a “Transaction Callgraph” diagram created by ADDI that shows the program HCIPDB01 that the developer will make updates. This program is used by CICS and accesses a Db2 table named PATIENT.

Since this program interacts with other programs one change to it could break other programs and this is what the developer has to verify in this use case using VTP.

In this article we chose CICS and Db2 as an example, but VTP supports batch executions, as well as IMS and MQ.

Steps performed by the developer to use VTP

One important point to be considered when using VTP is that the developer can use any kind of development environment.  He could use the traditional ISPF as well modern IDEs like IDz and VSCode.

The steps that our developer performs in this article are:

1. Use VTP to record the CICS/Db2 application in action
2. Run a batch execution to execute the recorded replay sequence
3. Modify the program HCIPDB01 introducing a bug .
4. Rerun the VTP test case batch execution and verify the bug introduced
5. Using VTP and Debug to verify the error that was introduced
6. Remove the bug and run the batch execution again, verifying that the error is removed.

In this article you will see examples of those activities.

1.    Developer uses VTP to record the CICS/Db2 application in action

In this step the developer records all possible test cases of the COBOL/CICS/Db2 application using the environment that this application run.  In this step CICS and Db2 must be active.

During this recording VTP intercepts calls made by application programs to various subsystems or other programs and captures details about those calls.

Once this data is recorded, those same application programs can be rerun in batch, without the need for the original test environment, and be fed back the values from the recorded data

The picture below shows (blue area) this step performed on the CICS/Db2 environment.

This is done once, and in the environment where you have the application running.

Once the test cases are completed the program updates and tests will be done without using CICS and Db2. The tests will run using batch execution via JCL submission.

In fact the developer could make the changes in any other  Z/OS (example other LPAR or ZD&T) once he moves the recorded data (also known as “playback file”) to this system.

For this example using a 3270-terminal using CICS the developer will perform the tasks below:

1. Start a VTP provided CICS transaction named BZUS that will activate the VTP on Z/OS.
2. Use the HCAZ transaction to start the application and interact with the various 3270 screens. The ideal would stress all possible conditions in the dialogs to ensure that all programs used on this application are executed.
3. Stop the VTP environment using a provided CICS transaction named  BZUE
4. Write all records on the playback file using the VTP provided CICS transaction BZUW
5. Close the CICS Transient Data Queue (TDQ)  BZUQ and inquiry using  CEMT INQ TD(BZUQ) as shown below.

A CICS TDQ was created on Z/OS.  This is the playback file.   Now a batch job may be submitted using a JCL that has this  playback file ( BZU100.ZUNIT.PLAYBACK) required to run the test case.

The best practice would be making a copy of this playback file and storing in an artifact repository, so it could be retrieved when required to run in another environment.

Using any tool like ISPF or IDz  the developer will submit a JCL to execute on z/OS that will verify the sequence recorded by VTP against the COBOL/CICS/Db2 programs.

Notice that at this point CICS or DB2 can be down, this execution does not use either CICS or DB2. The LOADLIB with the executables must be available as well the playback file created on previous step during the recording.Below one example of this JCL that will be submitted..

This execution must have the return code 0,  since the execution will match all the recordings, no mismatches.  Also notice that there are different options during this run. For example the TRACE=Y gives a detailed report.
Below is part of this execution where the return code is 0 with trace active.

Scrolling the report the developer verifies that on line 97 the program  HCIPDB01 uses a Db2 table (it has DB2 CALL=SELECT).

3. Developer modify the program HCIPDB01 introducing a bug .

The developer will make a change on the program HCIPDB01 to introduce a new feature and during this update he introduces a bug.

One common example is when changing a COPY book that is used in other programs. Once a copybook is changed all programs that use that copybook will need to be tested again.

To simplify this exercise we just add a few statements that change the patient’s name when the patient id is number 1.

Below the change implemented:

This program needs to be recompiled and re-link edited, but to test the change using VTP no Db2 bind is required even though this program has Db2 and also we do not need the CICS for the VTP test run.

After a clear COBOL compilation and re-link edit the developer uses his favorite IDE to submit the new JCL for a batch run.

Here VTP will flag a mismatch. Instead of the Patient named “Ralph“ that was recorded using CICS/Db2 it receives “BAD NAME”.  This is the bug introduced.  Noticed that if it was a copybook change probably many other programs would have mismatches.

Below the example of this mismatch after retrieving this JCL run.  Also the return code of this execution now is 4 instead of 0.

After the release of  VTP version 2.0 it is also possible to setup a VTP viewer and get better reports from the test run.  More details on the IBM docs site.
Below is one example of this report using a Web browser.

One very nice capability is to debug the code using a Debug while running the JCL batch execution. Again there is no need to have CICS and or Db2 on this environment. To execute this capability now the z/OS must have a Debug engine installed. In our example we are using the z/OS Debugger that is part of IDz.

Below the JCL that will run the tests using VTP and  Debug the COBOL programs. Notice that in this case the developer will use IDz for the debug and the Z/OS connection is via the user id connected to IDz, there is no need of using the client TCPIP address and the firewalls will not block the debug execution.

When using IDz once the programs are executing the debug perspective starts.  There is a capability named “Delay Debug Mode “  that is being explored here.  This allows you to filter only the program that you want to debug (HCIPDB01).

Below is one example of the debug in action showing the bug introduced by the developer.

Also once the developer can do the Debug he will also be able to do Code Coverage.

From the JCL example showed here the statements below would allow the Code Coverage instead of Debug.

Below is one example provided by the Code Coverage report.

In this step the developer will remove the bug  commenting the lines that caused the bug.

Again the program HCIPDB01 needs to be recompiled and re linked, but no Db2 bind is required for the VTP test run. Also CICS or Db2 are not required.

Once the VTP JCL batch is executed the return code is zero and no mismatches were detected.

Once there are no mismatches means that all test cases recorded passed successfully. The developer is happy and can get some rest 😊.

Conclusion

As demonstrated in this article VTP would bring a new way to implement best practices like shift-left testing, where application integration testing occurs earlier in the development process, allowing problems to be discovered sooner.

In summary VTP could be used in many other use cases as the examples below:

• Compiler upgrades – User records test cases with the current compiler, then recompile all programs using the new compiler version and then replay the tests. The mismatches will be identified.
• Automatic Binary Optimization (ABO) users – You record application test cases with the current executable, run ABO to optimize the load modules and then replay the tests.  The mismatches will be identified.
• Defect detected in user software – This is the use case demonstrated in this article. Also notice that the batch execution can be added to a CI/CD pipeline for continuous automation testing.
• Continuous automation – You record transactions and programs for automatic replay execution when software changes have been committed. The test cases execution can be done on any LPAR or even zD&T.  You do not need to have the environment ready for this run (no CICS, Db2, IMS etc).
• Developer debugging and testing – The developer takes a recording then can use the debugger with replay, to allow debugging of transactions and programs without the need for the middleware running. This provides a stable and isolated environment to debug in.
• Negative testing – record tests that utilize the “unhappy” paths through code. These recordings can then be added to a CI/CD pipeline to automate tests on user code that many times, is not tested.

You may experiment with VTP as well ZUnit using a provided z/OS on Cloud, by visiting the IBM Z Software trails  web site.