I expected June to be the first skirmish in a long battle between Neon Enterprise Software and IBM over software...
that could reduce licensing costs for customers running mainframes. Instead, on May 31, it was all over. Let's review the history of this conflict, the resulting settlement, and consider what the outcome means for mainframes and users.
Background info on the Neon zPrime, IBM case
Earlier this century, IBM introduced specialty processors in three flavors: Integrated Facility for Linux (IFL), System z Application Assist Processor (zAAP) for Java and XML workloads, and System z Integrated Information Processor ( zIIP) for other workloads that meet certain criteria. IBM originally touted specialty processors as low-cost alternatives to general processors, because they were cheaper to install and maintain, and they circumvented some software licensing costs.
The last item was probably the biggest attraction, as software represents a large part of any big iron budget, and capacity-based licenses consume more of your budget with every processor upgrade made. However, it soon became apparent that specialty engines were also marketing tools, designed to support workloads in danger of moving off mainframes.
Despite IBM’s hype, things worked out a little differently. IFL s did well as customers decided to aggregate Linux instances on mainframe hardware. ZAAPs proved useful for any shop running Java on mainframes. The zIIPs were a little problematic, as there were specific restrictions for using them, as well as the notorious “generosity factor” throttling mechanism, which limits the percentage of time that a given workload can run on a zIIP. In the meantime, customers continued to search for ways to lower IT costs.
With perfect timing, Neon’s zPrime entered the mix--a software designed to run previously ineligible workloads on specialty processors. This caused a couple of immediate problems for IBM and independent software vendors (ISVs). First, Neon had figured out how to get workloads onto the specialty engines without IBM’s licensed interface. Second, IBM stood to lose hardware income, as specialty engines were cheaper. Lastly, and most significantly, zPrime represented a significant threat to revenue generated from capacity-based software contracts.
IBM struck back with a fear, uncertainty and doubt campaign that was designed to keep customers in line, causing Neon to sue IBM for unfair trade practices. IBM countersued, alleging Neon stole trade secrets, at one point famously comparing Neon to a technician offering illegal cable hookups. In the meantime, some mainframe customers jumped on the bandwagon while the rest waited to see what would happen next.
Soon after, the case went to court in Austin, Texas, where both sides gathered evidence and took depositions until April 2011. Jury selection was slated to begin in June.
The final verdict
The crux of the matter came down to what IBM's customer contracts meant by “authorized workloads.” IBM argued that only IBM-approved workloads, or code using IBM’s official licensed zIIP interface, were legal to run on zIIPs. Neon contended there was nothing in IBM’s contracts that imposed any limitations on specialty engine use.
On May 31, U.S. Magistrate Judge Andrew Austin agreed with IBM's interpretation of the customer contracts, which led to Neon's decision to settle the lawsuit. Neon's press release announcing the settlement includes a summary of the decision that says IBM alone has the right to authorize which workloads can run on specialty engines. The press release ends by noting that Neon agrees to immediately stop selling zPrime and asks customers to uninstall the software and destroy the installation materials.
The effects of the settlement
The settlement immediately affects current zPrime customers who may have to buy a lot of general processors in a hurry to make up for the loss of the specialty engine capacity. IBM hasn’t given any indication of a grace period for removing zPrime, nor how it will treat customers that fail to remove zPrime software.
But the long-term prospects are more troublesome. This ruling effectively squashes any present and future software products similar to zPrime. It also makes any mainframe customer think twice about developing a way of getting work onto zIIPs or zAAPs. From now on, IBM is the gatekeeper who will have the final say on what the specialty processors do.
Whether this is a true victory for IBM depends on what they do going forward. IBM gets to protect its good name and intellectual property. But, given the expense of mainframes and its shrinking installed base, this is not the right time to put the screws to its customers. If IBM is smart, it will take this opportunity to rebuild customer relationships and, perhaps, loosen some of the rules around specialty processors. Getting serious about other ways to reduce mainframe expenses, hardware and software would be nice too.
The settlement puts customers back at the mercy of IBM and ISVs for finding specialty engine workloads. Traditionally, getting work onto zIIPs is difficult, considering the restrictions placed around them and the dreaded generosity factor. As badly as IBM wants specialty engines to draw or keep work on the mainframe, if the barriers to getting on them are too high, customers will seek solutions on other platforms.
On June 17, BMC Software Inc. announced its acquisition of Neon’s IMS database utilities. This leaves Neon with a very limited product portfolio. It may also leave some customers pondering the future of a software company that was once brave enough to take on IBM.
While we’re on the subject, here’s an interesting patent application from BMC explaining a method for getting work onto zIIP’s. It begs the question of whether it is the same algorithm zPrime used. The point may be moot as the technology is part of BMC’s intellectual property now.
About the author: Robert Crawford has been a systems programmer for 29 years. While specializing in CICS technical support he has also worked with VSAM, DB2, IMS and assorted other mainframe products. He has programmed in Assembler, Rexx, C, C++, PL/1 and COBOL. The latest phase in his career finds him an operations architect responsible for establishing mainframe strategy and direction for a large Insurance company. He lives and works with his family in south Texas.