Test virtualization accelerates mainframe testing

Automate mainframe testing and simplify complex tests

This article describes test virtualization scenarios for mainframe development. IBM Rational Test Virtualization Services and IBM Rational Test Workbench are used to provide the virtual services for the mainframe application. A sample demonstrates how to virtualize a CICS program and use the virtual stub in testing.


Zhang Hong Chen (chenzhh@cn.ibm.com), Enterprise Modernization Solution Architect, IBM

author photoTony (Chen Zhang Hong) is a Senior Software Engineer within the IBM Rational development organization. He is the architect of continuous integration for System z solution. The solution enables mainframe development organizations to apply DevOps practices by using Rational Team Concert, Rational Quality Manager, Rational Developer for System z, Rational Test Workbench, IBM Rational Development and Test Environment for System z and IBM UrbanCode Deploy.

John Chewter (john.chewter@uk.ibm.com), Chief Architect, Green Hat Technologies, IBM

John Chewter is an IBM Senior Technical Staff Member and Chief Architect for the Green Hat technologies. Based in the UK, he has more than 25 years experience in the software industry and has spent the last decade working in the field of Integration Testing and Service Virtualization.

Rosalind Radcliffe (rradclif@us.ibm.com), Distinguished Engineer, Enterprise Modernization Architect, IBM

Author photoRosalind Radcliffe is a Distinguished Engineer within IBM Rational Enterprise Modernization organization. She is an Enterprise Modernization Architect responsible for driving the DevOps for System z and Power architecture and the architecture for the collaborative management capability for enterprise solutions. This responsibility includes UrbanCode Deploy and Rational Team Concert support for standard mainframe development activities. Prior to Rational, she was in Tivoli responsible for the Service Oriented Architecture management strategy for IBM.

04 February 2014

Also available in Chinese Spanish

Test virtualization helps mainframe testing

Today's applications are complex. They spread across multiple systems and have many interdependent parts. Complex applications require complex tests, which need time and resources to set up. Test teams that work on different parts of an application have to coordinate test efforts. One solution to these limitations is to provide virtualization for parts of the application.

For example, for a mobile application that calls a web service, you can virtualize the responses of the web service, so that you can develop your mobile, front-end system without the need of the back-end system, at least for the early testing. The same principle is true for any boundary in an application, where you can split the application into a reasonable set of defined responses. With the application divided at the boundaries, the teams can build their application changes and test them, even though they do not have access to the entire application. This division makes it possible for test teams to work for a longer percentage of the development cycle. This suggestion can be particularly helpful with mainframe application testing where access to test resources is generally limited and where separate components need to interact with each other. Test virtualization works by identifying appropriate boundaries at which the technology can be applied. In the context of mainframe testing, this is typically from component to component.

But how do you virtualize parts of an application? Software engineers are familiar with test stubs, which are programs that simulate the behavior of software components that the module under test, depends on. Test stubs make it possible to perform tests earlier in the cycle, at reduced cost. However, when the system under test grows large and complex, stubs quickly become too difficult to create and to manage. The IBM test virtualization solution uses the stub concept and provides comprehensive functions that create, use, and share virtual services (also called stubs). To create a virtual service, you record it in a real system or you analyze the service interface definition. A team server then manages the services, which can be deployed to multiple test environments. The solution accelerates the delivery of complex test environments and makes it possible for development teams to do tests earlier and more frequently in the project lifecycle.

Test virtualization has many benefits for an enterprise system that includes mobile or web channels, mainframe transaction managers, such as IBM® CICS®, IBM® IMS™, and mainframe message servers and databases. It makes it possible to:

  • Set up multiple test environments in minutes, rather than weeks
  • Test multiplatform applications that produce and consume COBOL copybooks and data files and interact with IBM® WebSphere® MQ, IBM® DB2®, and other systems by use of virtualized, complex dependencies
  • Improve coverage for integration and negative test scenarios
  • Improve coverage for latency tests by simulating application behavior that takes too long to respond
  • Perform early performance tests to ensure the robustness of the system under test
  • Develop, in parallel, different parts of an application or system by use of virtualized dependencies
  • Reduce competition for critical mainframe resources

This article describes different test virtualization scenarios in the mainframe and steps through a sample of how to virtualize a CICS program. The approach used in the sample also applies to other middleware and service protocols.

Mainframe test virtualization scenarios

Different types of test virtualization are possible for the mainframe environment. The scenarios in this article focus on specific, mainframe connectivity options and are not an exhaustive list of virtualization possibilities.

CICS virtualization: Mainframe or distributed app calls CICS program

In Scenario 1, a mainframe or distributed application calls a CICS program by using the HTTP or HTTPS protocol, as shown in Figure 1.

This virtualization takes advantage of CICS support for web services, which makes it possible for a CICS program to be exposed as a web service with a minimum amount of programming effort. Such CICS services can be virtualized, regardless of the client-side technology.

Figure 1. Scenario 1: Mainframe or distributed app calls CICS program with HTTP
Mainframe app calls virtual back-end system

CICS virtualization: Distributed Java app calls CICS program

In Scenario 2, a distributed Java application calls a CICS program through the IBM CICS Transaction Gateway, as shown in Figure 2.

CICS Transaction Gateway serves as a connector for enterprise modernization of CICS assets. A CICS program can be virtualized if it is accessed through CICS Transaction Gateway by another application.

Figure 2. Distributed application calls CICS program through CICS Transaction Gateway
Distributed Java app calls virtual back-end system

CICS virtualization: CICS application calls a web service

In Scenario 3, a CICS application calls a web service by using the INVOKE WEBSERVICE command, as shown in Figure 3.

The downstream web service can be virtualized using the same technology as in scenario 1.

Figure 3. CICS program calls a web service with INVOKE WEBSERVICE calls
CICS mainframe app calls virtual web service

Scenarios 1, 2, and 3 are examples of inter-mainframe virtualization because the dependent system is usually in another platform or another IBM® z/OS® system.

CICS virtualization: CICS program calls another CICS program

Deploy with confidence

Consistently deliver high-quality software faster using DevOps services on IBM Bluemix. Sign up for a free Bluemix cloud trial, and get started.

In Scenario 4, a CICS program calls another CICS program by use of the distributed program link (DPL), as shown in Figure 4.

In CICS, DPL makes it possible for a CICS program to pass control to a second CICS program to run a function. The two programs can be in the same CICS region or in different regions. In this scenario, the linked-to program can be virtualized and call latency and ABENDs in the linked-to program can be simulated to assist with development or test scenarios that are typically difficult to achieve.

Because the application under test and its dependent application are in the same z/OS instance, this scenario is described as intra-mainframe virtualization. It allows mainframe development and quality assurance teams to use test virtualization technology within a large mainframe application.

Figure 4. CICS program calls another CICS program with distributed program link
CICS app uses DPL calls to call virtual CICS app

DB2 database virtualization

Access to host-based DB2 databases through Java database connectivity (JDBC) can be virtualized. The virtual database can run on a separate DB2 instance on z/OS or on the distributed platform, as shown in Figure 5. This setup makes it possible for you to create virtual databases that do not require z/OS to run. You can work with isolated copies of data that can be manipulated independently to achieve test goals.

Figure 5. DB2 database virtualization
App calls DB2 or virtual DB2 with JDBC

An IMS application can be virtualized if the application is called by a client, by using the IMS Connect protocol, as shown in Figure 6. You can record IMS type 1 and type 2 messages and use them to construct virtual program responses. Type 1 messages are generated from applications deployed on IBM® WebSphere® Application Server that are configured with the IBM® IMS™ Transaction Manager resource adapter. Type 2 messages are generated from user-written applications that use the IBM® IMS™ Enterprise Suite Connect API.

Figure 6. IMS virtualization
App uses IMS Connect to virtual back-end system

WebSphere MQ virtualization

Programs that interact with message queuing services provided by WebSphere MQ (both z/OS and the distributed version) can be virtualized, as shown in Figure 7. In addition to the normal running of stubs, IBM® Rational® Test Workbench provides the sift and pass-through capability that makes it possible for you to run both real and virtual services at the same time and seamlessly filter a subset of messages to either the real or virtual services. Previously, only a real service or a virtual service could be up at one time, because simultaneous usage results in contention for the messages being used. The benefits are obvious. You can focus on a subset of messages (among millions of messages) to simulate and test, and let the other messages go to the live system.

Figure 7. WebSphere MQ virtualization
Client through MQ to virtual services

Example of CICS DPL virtualization

In this example, see how a mainframe team uses CICS DPL virtualization to help them remove the dependency on other modules so that they can test early. You can apply a similar approach to any other scenario where test virtualization is supported.

A fictitious company JKE Banking is currently implementing a number of modernization programs across their application portfolio. The company wants to improve the user experience of the loan query function of their mobile application to use geolocation data to obtain a list of providers. The company is also changing the Calculate Mortgage module that serves both the main, green-screen mortgage application and the Get Companies module used in the loan query function. Figure 8 shows how the modules and services are organized across CICS regions.

Figure 8. Architecture of mortgage application
Architecture of mortgage application

Because the team that makes the changes to Get Companies needs to iterate fast to stay aligned with the mobile development team, they choose to use test virtualization to avoid impact and dependency on the Mortgage Calculation module. Another way to avoid the dependency is to replicate the program in another region, but that option requires more time, because it depends on the availability of resources.

How to record interactions

Before you can record DPL calls, you need to install the IBM® Rational® Integration Tester and the IBM® CICS® Transaction Server agent and configure them in the CICS region that is to make the DPL requests. After the agent is installed, run the CRITE transaction to start it, as shown in Figure 9.

Figure 9. Start the CICS Transaction Server agent in the Rational Integration Tester
Message: Rational Integration Tester is enabled

A test engineer on the team then uses Rational Integration Tester to record interactions and to create and edit the stub. As shown in Figure 10, the test engineer models a logical CICS region in Rational Integration Tester to represent the region from which to record and creates a corresponding physical resource that specifies the SYSID and APPLID to correctly identify the particular region.

Figure 10. Create logical CICS region in Rational Integration Tester
Rational Integration Tester creates CICS region

The logical resource then becomes added to the list of event monitors in the Recording Studio perspective of Rational Integration Tester. To start the recording, the tester clicks the red circle button recording icon as shown in Figure 11 to instruct the agent to capture all the DPL requests in the CICS region.

Figure 11. Record stubs in Rational Integration Tester
Rational Integration Tester client records a stub

Because both the Get Company service and the existing, green-screen CICS mortgage application make calls to the Calculate Mortgage module, you can use either of them to achieve the recording. In this example, the tester decides to use the green-screen application, a CICS transaction called JKEP, to do the recording because it is the simplest.

The tester logs into CICS and runs the JKEP transaction, inputs the loan amount, the years, and the interest rate, and presses Enter to tell the application to calculate the monthly payment. The screen shows the calculation result in the Monthly Payment field, as shown in Figure 12.

Figure 12. Mortgage 3270 interface
3270 screen of mortgage application

After this series of actions, two events appear in the Rational Integration Tester recording view, as shown in Figure 13. They are the request and response of the DPL call to the Calculate Mortgage module. The data fields in the request and response represent the COMMAREA, the CICS communication area in which data is passed to the program being invoked. To adapt them from their raw form, apply a copybook schema that is imported into Rational Integration Tester. After the schema is applied, the request and response data is then shown in a structured manner, which is easier for the tester to read and edit.

Figure 13. Events recorded in Rational Integration Tester
Rational Integration Tester shows recorded events

Click to see larger image

Figure 13. Events recorded in Rational Integration Tester

Rational Integration Tester shows recorded events

The test engineer then selects the pair of events and saves them as a simple stub, as shown in Figure 14. A stub can contain many event pairs that represent the different requests to be supported. When the stub is run and a DPL call comes in, it tries to match the request against the configured messages. If a match is found (you can apply a number of different matching rules that pick up matches that are not exact), the recorded response is sent back.

Figure 14. Save the stub in Rational Integration Tester
Screenshot of the Save Stub action

Click to see larger image

Figure 14. Save the stub in Rational Integration Tester

Screenshot of the Save Stub action

As shown in Figure 15, to test the new stub, the engineer runs it within the workbench element of Rational Integration Tester, where the tester can make additional changes and add other scenarios. Because this is a design environment, the stub has limited throughput and can run for a limited time.

Figure 15. Run the stub in Rational Integration Tester
Console shows agent has started routing

Click to see larger image

Figure 15. Run the stub in Rational Integration Tester

Console shows agent has started routing

A stub can contain complex logic or a simple pre-built response. The stub has settings and properties that control its behavior. The response time property makes it possible for the test engineer to simulate the latency of the real-world service to confirm that the Get Companies program behaves correctly in this scenario. As shown in Figure 16, the response time is configured to vary between 20 and 50ms with a Gaussian distribution. This method to test performance against a long response-time setting is much easier than using real services to perform similar tests.

Figure 16. Stub properties define the response times
Response time for minimum and maximum delay

The test engineer can configure the behavior for requests that are not handled. This is known as sift-and-pass-through, and is another powerful stub behavior that you can easily configure. Logic is added to a stub to help it determine whether it should respond to a received request (known as sifting) or, when possible, to send the traffic for onward processing to the real system (known as pass-through.) Sift-and-pass-through is supported for MQ and CICS and other transports. In this example, the tester chooses to simulate an error, as shown in Figure 17.

Figure 17. Define the pass-through configuration
Simulate Error is selected as pass-through action

After these tasks are complete and the stub is tested and ready to use, it is then published to Rational Test Control Panel for other shared use.

Manage stubs in Rational Test Control Panel

Rational Test Control Panel is a team server you can use to manage virtual services and the agents that provide the infrastructure. You publish stubs from Rational Integration Tester to Rational Test Control Panel when they are ready to be used, as shown in Figure 18.

Figure 18. Publish stub to Rational Test Control Panel
Publish Stubs action in Test Factory

As shown in Figure 19, in a view in Rational Test Control Panel the test engineer is able to see the elements of the system under test, organized into domains and environments. From there the tester can launch and see the status of the stubs and the statistics of requests that are handled by the stub. From the test control panel, you can search logs and results and view the status of agents.

Figure 19. Rational Test Control Panel VIE view
Elements under test are listed in view

Click to see larger image

Figure 19. Rational Test Control Panel VIE view

Elements under test are listed in view

Continuous testing with UrbanCode Deploy

Many development teams have moved toward automated environment management and automated deployment as part of their build cycle. You can include virtual services as part of the test environment and as part of the deployment process. In the JKE Banking example, the bank uses IBM® UrbanCode® Deploy, a leading deployment automation product, to deploy their mobile and mainframe application to a test environment to run their regression tests. UrbanCode Deploy includes a plug-in to work with the virtual services created by Rational Integration Tester.

As shown in Figure 20, an UrbanCode Deploy test process is enhanced to use a virtual service. The Start Stub and Stop Stub steps in the process diagram communicate with a Rational Test Control Panel server to ensure the required stubs can be used for this test scenario.

Figure 20. Deploy stubs with UrbanCode Deploy
UrbanCode Deploy process with stub deployment

Rational Test Control Panel also provides integration APIs in the form of REST services, custom ANT tasks, and a command line client to make it possible for other test and deployment automation tools to use the test virtualization capabilities.

Use Rational Development and Test to prepare test environment

IBM® Rational® Development and Test Environment for System z® is an environment for mainframe application development and testing where the operating systems, middleware, and software can run on Intel and Intel-compatible platforms without the need for System z mainframe hardware. With this test environment, developers and testers are able to work independently of each other and use test virtualization technology to prepare an environment for a mainframe project much faster then before. Development can iterate on this environment using virtual third-party services until the time they need to integrate with the real sub-systems.


This article describes the types of test virtualization scenarios that are supported in z/OS. It includes a sample of how to create a virtual service for a CICS program and use it in a team environment. Test virtualization and Rational Development and Test work together to simplify z/OS test environment preparation. For more information about continuous integration, deployment, and testing in mainframe environments, see the continuous integration for System z series of articles.



Get products and technologies

  • Download a free trial version of Rational software.
  • Evaluate other IBM software in the way that suits you best: Download it for a trial, try it online, use it in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement service-oriented architecture efficiently.
  • Try building and deploying your next project on the IBM Bluemix cloud platform, where you can take advantage of pre-built services, runtimes, frameworks, application lifecycle management, and continuous integration.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Rational software on developerWorks

ArticleTitle=Test virtualization accelerates mainframe testing