Problem solve Get help with specific problems with your technologies, process and projects.

Why IBM should listen to Neon Software, customers on zPrime

With high mainframe costs and the failure of mainframe specialty engines to deliver as promised, one expert thinks IBM and independent software vendors have a lot to learn from Neon Software and its zPrime application.

In July, Neon Enterprise Software introduced a new product called zPrime. As you've probably heard, zPrime allows previously ineligible workloads to run on mainframe specialty engines, a development that has agitated the mainframe world. On one side, there are customers tired of paying for expensive mainframe components; on the other side are IBM and independent software vendors (ISVs). While it's too early to know what will happen, I think it is important for IBM and ISVs to listen to their customers.

Mainframe specialty engines: An unfulfilled promise
IBM understands the mainframe's weaknesses better than anyone else and tried to address some of them with specialty engines.

More on zPrime:
Mainframe savings with zIIP, zAAP could go beyond DB2 and Java

IBM warns customers about Neon's zPrime
Neon CEO rejects IBM warnings on licensing issues due to zPrime

An interpreted language like Java doesn't run very well on big machines, so IBM introduced zAAP processors. The applications may still run slowly compared with traditional languages, but at least the processor is cheap.

Users were moving databases off the mainframe, so IBM created zIIPs to run client queries through Distributed Data Facility (DDF).

Finally, although not associated with an inherent mainframe flaw, IBM saw the potential of running Linux on System z hardware and created Integrated Facility for Linux (IFL) on the z boxes.

IBM designed these specialty engines as part of a plan to tackle mainframe total cost of ownership (TCO) in two ways. First, specialty engines can be purchased at a one-time charge and would be carried forward through upgrades to new models. Second, IBM reached an agreement with ISVs that specialty engines wouldn't count toward capacity-based software licenses. Years later, we have mixed results.

The failure of specialty engines to pay off, combined with high mainframe costs, has created a disaffected customer base searching for ways to save.

IFLs appear to be the most successful of the specialty engines. There are a lot of then around, and some customers successfully consolidated many Unix systems onto big iron. But not everyone runs Linux or is all that eager to put it on a mainframe. In addition, a much ballyhooed case study involving Nationwide Insurance lost a lot of steam when a closer look revealed the best candidates for consolidation were running at very low utilization rates, something that could also be managed through less disruptive means.

The zAAP engines are very beneficial for companies that can take advantage of them. However, there were significant barriers getting to Java. For instance, until recently, IMS was unable to run Java in concert with other languages. Other infrastructure, such as CICS, provided disincentives for Java by supporting wrappers enabling existing COBOL applications to interact with the Web. Older applications that did get a makeover into Java tended to follow the simpler migration path to a distributed platform.

The zIIP processors seemed the most promising, especially when IBM added zIIP support to database utilities and several vendors followed suit in other types of software. But this piecemeal approach rarely drives the available zIIP engines to full utilization. IBM also set the bar fairly high, as any ISV wishing to run zIIP must license IBM's zIIP application programming interfaces (APIs) and adhere to certain restrictions. Then, a couple of years ago, it came to light that the operating system has a hidden "generosity factor" that governs the percentage of zIIP processor available to a workload. IBM's customers don't know for sure what the percentage is, but chances are it is not 100.

What next for IBM and Neon Software?
The current implementation of specialty engines resulted in disappointing utilization rates. The failure of specialty engines to pay off, combined with continually increasing mainframe costs, has created a disaffected customer base desperately searching for ways to save money. Into this atmosphere comes Neon, with its game-changing software.

Neon is playing the giant killer and many IBM customers see zPrime as a chance to strike back. IBM, on the other hand, reacted by quietly and sternly warning customers to ensure zPrime doesn't violate their contracts.

IBM's initial reaction makes one wonder if there may be more going on in the background that we don't see. Maybe IBM is talking to its lawyers or hosting strategy sessions. It may even be in negotiations with Neon to arrive at some sort of compromise.

Whatever happens, IBM should not lose this opportunity to listen to its customers and think about why they reacted the way they did to zPrime. One lesson may be that IBM can no longer appeal to mainframe patriotism with an "us against the distributed systems" battle cry, as mainframers find it harder and harder to defend an expensive platform.

The other lesson, both for IBM and ISVs, is a matter of simple economics: In these times, the bottom line is paramount, and data centers will move applications to cheaper platforms whether it makes technical sense or not. No number of case studies, no amount of sales pressure or inertia will stop it. Ultimately, whether Neon wins or not, this may be a good thing. If they listen closely enough, this might be the year that IBM and ISVs get it.

ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.

What did you think of this feature? Write to's Matt Stansberry about your data center concerns at

Dig Deeper on IBM system z and mainframe systems

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.