Mainframe developers have an easier time testing with the Wazi Virtual Testing Platform
Working with test data is tricky. If you’re a developer working in a distributed environment, things are difficult enough. It seems as though you’re forever replenishing test data on a database in your local system or one that’s dedicated to you out on the network.
You run tests that twiddle with that data and when things go wrong that data gets so corrupted. It’s useless. So you have to go through the whole replenishment process again. This is no big deal if you’re working with a few gigabytes of data, but when you’re running a test against a database that is really big—on the order of hundreds of gigabytes or a few terabytes of data—the replenishment process can take hours or, in some cases, days. It’s a lot of time-consuming work, even when a good deal of the process is automated.
As if this isn’t challenging enough, things get even more difficult when you’re executing tests that run in a multi-user scenario. You have a whole bunch of users making a whole bunch of changes to shared datasets that, in turn, affect the application’s overall state. When tests fail not only do you have to figure out if the problem is with the code, the data or both, you also have to determine where the failure occurred.
Remember, a distributed application is intended to run multiple instances of application logic that gets distributed over a cluster of machines. Figuring things out requires a lot of very detailed monitoring of all activity in all the instances of the application running over the network. And, determining the root cause of each failure requires a good deal of expertise to do the analysis successfully.
It’s a lot of work despite the fact that developers working on distributed applications have a lot of direct control over their environment. For mainframe developers, working with test data can be more than tricky; it can be a staggering challenge that tests the mettle of even the most gifted developer.
Understanding the Problem of Data Sharing on a Mainframe
There is a fundamental difference between the way data is managed in mainframe testing and distributed testing. Whereas a distributed developer “owns” the data in their environment, mainframe developers really don’t have such luxury unless they are working in dedicated subsystems. Typically a mainframe programmer’s programs are compiled binaries that are usually part of a larger unit of execution. An example of a larger unit of execution is the work that sets up a worker to receive unemployment insurance.
Let’s say that Sarah is a COBOL developer who has written a program that is part of the process that determines a worker’s unemployment benefit. Sarah’s program discovers all the worker’s employers over the last five years and adds the income from each employer to a table in a database that is shared with that other programs that are part of the unemployment benefits process.
Of course, Sarah will unit test her code. If she is working on a z/OS mainframe, she might use a product such as zUnit to do the testing. But, just testing Sarah’s code is only part of the work of the entire process; a broader range of testing is needed.
Now here’s where things get tricky: Sarah’s code is but one of many programs doing the work needed. So, while it’s entirely possible that her unit testing might be fine, once her program changes data and those changes are applied to the bigger picture things might go haywire. In such a case, if Sarah’s data corrupts the overall state of the unemployment benefits process, the data of all the other programs that interact with Sarah’s data might be corrupted, too. Thus, the entire database will need to be replenished. Remember, Sarah does not “own” that shared data; she is one of many users.
Sarah’s example is but one instance of a real problem that is a common, time-consuming headache for mainframe developers. If the data transformations made by Sarah’s program could be isolated and made reusable on demand, that capability would have far-reaching benefits that could change the way mainframe testing is conducted in the enterprise.
Fortunately, the capability exists. It’s the test recording feature of the Wazi Virtual Testing Platform.
Understanding the Mechanics of Test Recording
Test recording as implemented by the Wazi Virtual Test Platform (VTP) addresses two fundamental problems around managing data in a mainframe testing environment. The first problem is creating a way to isolate and make reusable the test data that is the result of the actions of one or many mainframe users. The second problem is creating a way to update that test data should it go stale.
Wazi VTP allows a developer or test practitioner to record the terminals of one or many users executing data query commands against a database. Wazi VTP saves the results of those queries for reuse as test data.
Wazi VTP has the capability to record CICS transactions or JCL batch jobs. CICS transactions can use any combination of CICS commands or Db2, DL/1 as well as MQSeries calls. Batch jobs can use dB2 or DL/1. Recording can be started from CICS by using the BZUS transaction command or from batch by running the application. All of this is done without any change to the user’s application programs.
Once the recording has completed, the CICS transactions or the batch job can be replayed entirely in batch, completely standalone and free from any subsystem. Since the data was originally recorded and then fed back to the replay process, it maintains the state of the data for all subsequent testing.
To stop recording using CICS, the developer enters the command, BZUE. Figure 1 below shows the command sequence from a conceptual point of view:
The commands to start and stop recording can be entered from a mainframe terminal as shown in Figure 2, below. The developer enters the command BZUS without any parameters to record only the queries executed from the terminal in which the command is invoked. This is shown in the upper-left portion of Figure 2 below. If the developer wants to record the activities of many terminals, they add a wildcard parameter as shown in the lower right of Figure 2. In this case, BZUS AB* is the command invoked to record the activities of terminals that have an ID starting with the characters AB. Also, the developer can record activity coming from a specific terminal by using the name of the specific terminal instead of a wildcard parameter.
When a developer wants to stop the record they enter the command BZUE.
Using Wazi VTP is not confined to 3270 terminals or terminal emulators. The Wazi VTP also supports an API that can be used to perform integration testing within a CI/CD workflow.
The important thing to remember is Wazi VTP does a lot more than capture screen activity. In fact, screen capture is but one tiny aspect of the data collected. Wazi VTP captures all of the arguments on all of the CICS, DB2 or DL/1 subsystem calls. And, as mentioned above, the data it collects can be used as test data.
Figure 3 below shows an example of recorded data and program call arguments. Notice that Wazi VTP has recorded both CICS and programs (PGMS) that are written in COBOL, PL/1 and Assembler, as indicated on the first column on the left of the screenshot shown below.
In addition to simply recording data that is then available as reusable mock data, Wazi VTP detects and then reports when data is changed. Detection is based on changes made by program logic. Wazi VTP allows those changes to the programming logic to continue to execute, until either a new, unrecorded path is attempted or until the program’s end.
This is a big difference from test data in the world of distributed computing. Unless precautionary measures are taken, once cloned instances of the test databases have no real insight into the state of those databases from which they were derived. Things might go well in unit, integration and performance testing only to blow up in production because the test data is completely out of sync with the real-world production data. Mainframe developers running Wazi VTP don’t have this problem.
Tracing Behavior and Gathering Statistics
One other advantage that Wazi VTP brings to mainframe testing is the ability to trace query behavior and gather statistics about the query behavior executed.
Figure 4 below shows how to invoke tracing under 3270 emulation. The image on the upper left shows invoking a standard trace. The image on the lower right of the figure shows the call that invokes a deeper internal trace.
Figure 5 below shows the details that are the result of a standard trace.
Figure 6 below shows the richer set of details reported when an internal trace is invoked.
As mentioned above in addition to tracing, Wazi VTP will report statistics around test activities. Figure 7 below shows a set of statistics from a typical testing session conducted using Wazi VTP. Wazi VTP can report not only the number of times a program has been called but also the identifier of the caller. In addition, Wazi VTP reports status code that goes with different aspects of a CICS transaction.
Wazi VTP recording is a powerful feature. Being able to record and reuse test data reduces a significant amount of the burden that goes with data management for mainframe testing. Tracing and statistics-gathering capabilities add even more power—so much so, that mainframe testing using Wazi VTP in many ways surpasses the capabilities present in current distributed computing paradigms. This is no longer the “coders code, testers test,” waterfall-driven approach to testing that was common only decades ago. It’s a modern approach to the way that enterprise testing works in today’s world. In short, it’s very cool!
Mainframes Development Offers Opportunities for Everyone
I am a big fan of the opportunities presented by mainframe programming. The machines are powerhouses. They’ve been designed from the get-go to handle thousands of users simultaneously. Mainframe computers still handle over 80% of corporate data.
There remains a real need for mainframe programmers now and well into the foreseeable future, particularly as the existing workforce continues to age into retirement. I’ve counseled more than a few younger programmers to consider spending a year or two doing mainframe development. Mainframe programming experience provides a great fallback to get through the ups and downs of an increasingly volatile job market.
As the mainframe and distributed communities continue to cross-fertilize, it’s entirely possible for developers from all walks of life to work in either environment provided they have a clear, competent understanding of the general principles of software development as well as a solid appreciation of the best practices that are general to any type of programming environment. Once the basics are in place, all that remains is taking the time to learn the particulars of the programming landscape. In the past, this might take years. Today, with tools such as Wazi VTP, the learning curve can be reduced to a matter of months provided the developer is committed to doing the work necessary to get the skills required to contribute effectively to the work at hand.
Wazi VTP is a compelling, state-of-the-art testing platform for mainframe developers. But it’s potential is much broader: Wazi VTP brings mainframe development into a common development landscape. In many ways, Wazi VTP is a door that opens into a world of opportunities for all developers from any computing environment.
Check out IBM® Wazi Virtual Test Platform Demo: https://mediacenter.ibm.com/media/t/1_tbcimobz
It’s almost a no brainer. Yet, there’s still a lot of perception out there that TDD’s dictum to write the test first slows down the development process. The thinking goes that if a developer is going to write a test for the code before writing the code, just save time and write the code anyway and then write the tests only for critical parts of the code.
