You are currently on IBM Systems Media’s archival website. Click here to view our new website.

MAINFRAME > Administrator > Systems Management

Automate z Systems Application Testing on the Cloud

Recently, a major European bank was fined about $88 million by U.K. regulators. The fine was a result of investigations by regulators of a series of software and procedural failures that interacted to take most of their retail operations offline for several days in 2012.

The investigation revealed that the bank did not have adequate z Systems or governance. In addition to the fines, the bank paid about another $109 million to cover damages incurred by their customers. The total bill for the failure was in excess of $197 million.

Preserving the integrity of the production environment to avoid nightmare scenarios like this is the rationale for investments in robust change and quality management practices.

The day-to-day reality of maintaining a change and lifecycle management infrastructure is an effort to maximize efficiency and effectiveness in test and release processes while consuming as few MIPS as possible. As the incident shows, some efforts to reduce non-production MIPS consumption, such as scaling back on testing, turn out to be false economies.

A readily available z/OS environment, with a suite of well-designed validation tests that can run automatically on demand as part of a routine build process and without a dependency on production resources, would help to reduce the temptation to seek ill-advised shortcuts.

Time to Value Versus Safeguarding Production

Notwithstanding experiences like above, for mainframe shops “time to value” and “safeguarding production” are perceived to be in conflict. Investments in safeguarding production are said to affect the bottom line, increasing the time and effort needed to bring a new solution online and start generating revenue.

There are other complications: the dilemma of allocating mainframe capacity between production workloads and non-production workloads, and the routine administrative burden of provisioning even simple non-production environments. These conspire to inhibit continuous development, and automated build, test and deployment in mainframe shops.

These obstacles—real or perceived—could be overcome with a dedicated z/OS environment hosted elsewhere than on the production mainframe hardware, making it reliably available and not dependent on the financial and administrative overhead of affecting production workloads.

A MIPS-free Mainframe Development and Test Solution?

Since late 2010, IBM has offered a low-cost alternative for organizations that are struggling with managing growing demands for mainframe capacity: Rational Development and Test Environment for System z (RD&T).

RD&T is a packaged z/OS environment, with a middleware stack that supports a typical workflow for development and testing of mainframe applications. It runs on Intel-compatible hardware, not on z Systems hardware, so it can be hosted on any adequately sized Intel-compatible server. If you prefer an off-premises solution, RD&T as a Managed Service (RD&TaaMS) offers RD&T in the Cloud via IBM SoftLayer.

RD&T: A Close Look

RD&T uses a set of Linux software device driver programs that act to recreate, in software, the hardware environment of a z Systems platform. What runs on top of this is z/OS, and a set of middleware solutions typically used in application development and test.

RD&T is intended as a standalone development and test solution, completely independent of the production environment. It offers the developer an individual, authentic z/OS environment to work in parallel with colleagues without the risk of inadvertently corrupting one another's work or the production environment (see Figure 1).

How RD&T Helps

Self Testing Builds
A continuous build process with test-driven development and automated regression testing is a goal of many z/OS shops. The lack of readily available test environments is one of the impediments. RD&T can change that. With a continuously available RD&T, builds can be self-testing. Build scripts can be written to automatically invoke unit tests whenever a build is run. Services normally available in the production environment (e.g., MQ, CICS) can be virtualized on RD&T with Rational Integration Tester (RIT). RD&T and RIT make possible extensive functional testing with almost no dependencies on production resources.

Reduced Repair Costs
It has long been known that the cost of remediating a defect discovered early in the workflow (e.g., in design and implementation) is a fraction of the cost of remediating the same defect discovered in later stages. The increasing costs are mostly due to the increased difficulty in problem determination, and “wasted” time and effort of the procedural steps of delivering and validating code that was presumed to be correct, which must be repeated when the corrections are made.

The value that RD&T can bring by helping to shift defect discovery to the left is seen in Figure 2 and is based on data compiled by IBM's z Systems Sciences Institute. Assume that a defect discovered in production is introduced in design or implementation, which is common. If one also assumes that the designer or developer had available to them, on demand, an easily accessible, live z/OS environment for prototyping, the chances are they would have observed the defect earlier in the process. A defect that cost $25,000 to remediate in production would have cost $1,625 if found during implementation, and just $250 if found during design.

Historically, the overhead of maintaining an authentic z/OS environment for incremental, real-time validation of code as it is produced was viewed as prohibitive. The resulting behavior was to try to “test” quality into a product in the latter stages—in the so-called quality assurance cycle—months after the code was written, instead of testing as you go (“continuously”) during the development stage.

The practice of shifting the detection of defects to earlier phases of the development cycle—“shift left” in Figure 2—saves money in the form of reduced effort to investigate and rework, and reduced time to production. A properly configured z/OS test environment, introduced further upstream, which can be easily deployed and which does not depend on production hardware or MIPS, can remove a significant obstacle to continuous testing and integration.

With RD&T, the overhead of providing test environments for developer teams is much smaller, to a point where it becomes cost effective to keep them continuously available. Developers can test continuously as they implement. In sum, RD&T brings shift left to mainframe developers.

David Lawrence is worldwide technical enablement manager and COP lead, DevOps for Enterprise z Systems IBM Rational Software Group.

Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Active Energy Manager Pulls Resources Together

Integration with InfraStruXure Centeral provides single management interface.

Amplifying Your Energy Efficiency

IBM BladeCenter and virtualization team up for greener data centers

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters