Cutting into mainframe Opex

Saving anything on operational expenses is one of the constant concerns of CIOs and IT managers, particularly when the level of business is under the cosh from a tough economic environment. The mainframe sector is no different in this respect, so the arrival of zPrime from NEON Enterprise Software back in June was bound to create waves, for it offers the opportunity to generate significant savings in both operational expense and time, while providing a kicker for the throughput of business applications.

The target for NEON’s development effort was two of the specialty processors offered by IBM for the z/Series mainframe systems. These are the z/Series Integrated Information Processor (zIIP) and the z/Series Application Assist Processor (zAAP), both of which are intended to run specific, dedicated applications workloads that accessed the processors via specific APIs. The advantage for users was, and has proved to be, that the specialty processors are a one-off purchase which are exactly the same as the main General Purpose Processor (GPP) of the system. Once bought, however, they are then free to run at maximum speed. The performance of the GPP is limited by the number of MSUs (Millions of Service Units) specified in the licence the user takes out with IBM. NEON realised that if users could exploit the zIIP and zAAP processors without using the IBM API, then the systems could be used without restriction to run other applications.

NEON’s approach has been to create an environment which exploits the documented user exits created by IBM for its own applications and languages, such as the CICS/PLT Exit, the IMS Pre-Initialisation Exit, LE Exit, TSO Select Exit, DB2 Sign on authorisation Exit and so on. These have been strategically picked by NEON to enable customer application code based on these IBM tools to run on the specialty processors. When the business application is started, the exits are used to provide an interface with zPrime, which then creates an environment within the applications address space that allows the z/OS operating system to make that workload eligible for zIIP or zAAP enablement.

This is therefore allowing the operating system to do what it normally does, but do it with application code that it normally would not work with in that way. z/OS is never instructed by zPrime to move the workload to the zIIP or zAAP, but the process provides a way of telling the OS dispatcher that the workload is eligible to be moved. There are, however, no changes made to either the application code or z/OS and, by not altering the code, users maintain operational stability. In essence, the zPrime system simply tells the operating system that the application is eligible to be moved to the specialty processors.

Whether it is moved or not is up to the operating system, with the decision driven by the dispatcher and the dispatch priorities set by all the applications being run. If the MSU limits of the user’s licence are about to be breached any eligible workload can be moved to a specialty processor rather than queued. The set up of the user’s system, the WLM settings, server policies and dispatching priorities remains the same, so the user can still control every aspect of operation in the normal fashion. The application just happens to run on the zIIP and or the zAAP rather than the GPP.

As a side issue, for mainframe systems fitted with both types of specialty processors, zPrime checks with z/OS real-time to determine which processor, the zIIP or zAAP, is least utilised and then creates an environment for that processor on the fly. This means that users do not have to pre-define which applications should run on what specialty processor. However, the z/OS dispatcher, working with WLM, still makes the decision as to when and where the work gets dispatched-just as it always does.

The arrival of zPrime has certainly stirred the IBM mainframe waters. Many companies in the user community have received letters about it from IBM, and the company has also enquired of NEON for details about how zPrime works. NEON has hired ‘a very famous law firm’ and a software forensics expert to go through all the zPrime code and make sure that none of it makes improper use of the intellectual property of IBM or any other company and has been given a ‘very clean bill of health’, according to CEO Lacy Edwards. In addition, since its launch some 50 companies have set their own legal teams to review their contracts to look for violations, and nothing has been found. NEON now has 148 companies either evaluating zPrime, or committed to making the evaluation.

It can be argued that IBM’s pricing policies on mainframe systems are still firmly rooted in the 1970s, and the initial interest shown in zPrime evaluations would seem to show a growing number of users agree with it. Though IBM is keen to put forward the green credentials of the z/10 system, particularly in terms of its performance and energy consumption, the figures have tended to highlight the operational cost advantages when the machine is used as a platform for high density virtualised Linux servers. With the GPP licence terms able to limit the performance available to users, the mainframe still ends up with a hardware-centric pricing policy that now runs counter to almost every other branch of IT.

So, the ability to free up the dispatcher to utilise specialty processors for a much broader set of applications is an obvious advantage for users, many of which have already invested in specialty processors for the applications that specifically require them, such as zAAPs use with the growing range of Java-based applications now found on mainframes. There is a side issue involving licencing here, in that many licences-for third party products, as well as IBM’s-are geared to the MSUs used on the GPP. When applications are transferred to the speciality processors the number of GPP MSUs consumed is reduced, reducing the licence payments due to all the licence holders associated with that application.

Estimates of reduction in Opex are, of course, very dependent on the size of the installation and the mix of applications, but Edwards suggests Opex savings will generally lie within 15-30% depending on the specific application mix and workloads. As examples, he references such customers as a large credit card company that claims zPrime can save them $20-30 million a year, a large bank that has an estimated first year saving of $48 million, and an insurance company that estimates an Opex reduction of around 20%.

When it comes to overall performance improvement he cites as an example a customer with a backup program that ran for seven days per month on a heavily capped z/10. The company bought a specialty processor and zPrime and the job now runs in two days.

A subsidiary but important issue for IT managers is the inevitable sales cycle time and the consequent Return on Investment. Nine to 12 months is a typical time line on the sales cycle for mainframe applications but, according to Edwards, the current record, from signing up for zPrime to operation in the production environment, is six weeks.

For now, the company is concentrating on user-generated applications written using the exits provided by IBM in CICS, DB2, PL/1, Cobol and the like. So far it has not attempted to implement zPrime for any third party applications, though is not ruling out the possibility. At a high level there is not a problem, as the third party vendors have already agreed not to charge any extra for running applications on speciality processors. However, part of the zPrime package is the need for users to opt in to making applications eligible using an ISPF interface which allows users to select which job is enabled. For now, at least, they are restricted in making any third party software eligible.

This does not mean NEON is ruling out enabling third party applications tools in the future, however. According to Edwards, the NEON position is that the customer owns the system and software and any decision to enable such an application will be theirs. In practice, it will depend upon ensuring that this does not violate any licence agreements and, once that is established, it will then be possible to undertake the work. A few customers have started to enquire about the possibilities but there could be investment implications for NEON in terms of development, as this would require taking on staff with the appropriate skills sets. So this move is likely to depend on a specific third party application project, or sufficient market demand for a third party application to be enabled, before the development would be started.

NEON is not the first company to exploit the specialty processors as potential resource for improving mainframe system throughput and performance. The DataDirect Division of Progress Software developed its own patented thread for the Shadow data integration middleware package which allowed access to the zIIP and zAAP. This provides a utility that allows users to write business applications, but these must run under the Shadow address space. This, according to NEON, is the key difference, in that Shadow requires existing applications to be changed so that they can operate within the Shadow address space, whereas NEON can run legacy applications unchanged in their own address space.