Lowering Mainframe TCO Through Specialty Engine Exploitation

In this podcast, Gregg Willhoit explains how specialty engines can lower the mainframe’s total cost of ownership. The podcast runs for 5:14.

To listen to the podcast, please click on the following link: http://blogs.datadirect.com/media/GreggWillhoit_LoweringMainframeTCO _2.mp3

Podcast text:

What are some ways to lower total cost of ownership on mainframes? In particular, there’s a lot of attention and interest right now on specialty engines. Can you explain what specialty engines are and how they work?

Gregg Willhoit:

Specialty engines are really special purpose System z processors. They’re really architecturally not different to the standard general purpose processors, or GPP. Specialty engines are limited sometimes in functionality. And they do allow specific workloads to run much more cost effectively on the Z platform, beginning with the IFL – which is the Integrated Facility for Linux, the first specialty engine. It provides basically a very cost effective platform for Linux consolidation to the Z Linux platform. The IFL and the Linux have proven to be very successful for IBM.

The next specialty engine that came out was the zAAP. The zAAP was originally designed for a Java workloads, so that mainframes could more efficiently and effectively run Java workloads, hoping to attract new Java types of development to the mainframe. Since then the usage of the zAAP has been expanded to include, for example, XML System Services when executed in TCB mode.

The next specialty engine to come out, and the most recent one, is the zIIP. The zIIP was originally designed to allow for business intelligence type queries, heavy duty queries, executed against DB2, and do so in a very cost effective manner. IBM wants DB2 to be used on the mainframe instead of migrating that data off, possibly onto a non-IBM platform. The zIIP, in combination with IBM’s DB2 on a mainframe, provide for a very cost effective strategy in that regard. The limitation of the usage of the zIPP is basically to applications which run in Enclave SRB mode. DB2 Connect has run in Enclave SRB mode for a very long period of time. So as soon as the zIIP was announced, DB2 was the first exploiter of the zIIP. And it does deliver a significant offload of CPU intensive queries to the zIIP, and therefore a much lower total cost of ownership.

Today’s zIIP usage has expanded beyond just DB2. There are many software vendors out there that are offering zIIP enabled products. Most of those vendors are in the utilities space. While there is some benefit to offloading utilities to the zIIP, the real bang for the buck comes from your data and transactional workloads that are driven via various online systems, or via various online systems in a SOA environment. These kinds of workloads typically use massive amounts of CPUs in a relationship to utilities, and therefore can deliver a much greater benefit with regard to zIIP offload.

Organizations should expect to see much lower TCO from the use of a specialty engine, and that lower TCO should improve over time. Specifically if an organization has endeavored to enter the SOAP environment, and is undergoing some CPU consumption due to the processing of XML – which is fairly computationally expensive – they’ll see immediate benefits with regards to offloading of XML processing to the zIIP. Other organizations that may not be exposing their legacy assets via XML or SOA, certainly are most likely exposing those assets via SQL, which is the ubiquitous API today. They will also see a significant offload with of the processing of SQL requests to the mainframe, and that includes SQL to non-relational as well.

The impact that some organizations will receive does vary somewhat by workload, and by the ratio of the processing time that occurs in the middleware product as apposed to accessing the backend data. In particular, if an organization uses fairly large XML documents and fairly transactional backend data or business logic access, they will see an extremely significant amount of reduction of TCO: close to 99 or 100% in some cases.

One of the benefits of this lower TCO and offload of this general purpose processer capacity to the zIIP is the freeing up of more expensive general purpose processor capacity. There is typically latent demand at most mainframe instillations. There are typically resource limitations with regards to CPU, and offloading a significant portion of the workload to the zIIP actually has an immediate effect of freeing up capacity to be used for either new projects, for example, or to improve response times for existing workloads that are resource constrained. Specifically, CPU resources constrained.

Besides the immediate capacity constraint alleviation with regards to the general purpose processor, there are quite possibly MSU based license cost benefits to offloading to the zIIP, where the application and the workload can run without regard to MSU based charges.

Basically, the application runs for free when it runs on the zIIP.