I know I’ve spoken about specialty engines before (about a year ago, in fact), but at the Virtual IMS Connection (www.virtualims.com) user group we were lucky to have an excellent presentation by Tom Harper, an IMS product author from NEON Enterprise Software. Tom has been in software development for 48 years and in that time helped start BMC Software, and is currently the Director of IT on the SHARE Board of Directors.
Tom started by looking at z/OS platform evolution and the big leap forward in around 1995 with the introduction of smaller CMOS processors. This heralded an era of large numbers of processors, large memory, a steeply dropping price/performance curve, and escalating software costs. This in turn led to a big change in software licence charges. Early software was often free, with vendors slow to realize its value. However, prices began to escalate out of control and customers tended to be locked in. IBM looked for a way to help, but they got caught up in software licence issues themselves.
One consequence in terms of hardware was the introduction of specialty processors. The first specialty processors were the Integrated Coupling Facility (ICF) and the Integrated Facility for Linux (IFL). The more recent specialty processors are the Integrated Information Processor (zIIP) and the Application Assist Processor (zAAP).
Tom suggested that IBM’s goal was to preserve existing hardware and software licence revenues, and to be competitive in “new” workloads. In order to achieve this, IBM’s plan was to create the concept of specialty processors, and (perhaps not surprisingly) do a great deal of marketing.
Tom went on to look at the construction of the processors in a CEC. He then told us that specialty processors are masked off from I/O interrupts and they are also masked off from timer interrupts.
Interestingly, IBM provided software vendors with a zIIP API in order to develop software to utilize the specialty engine. The API requires work to run in enclave SRB mode. However, SRB mode does not allow any SVCs to be issued except ABEND – which isn’t particularly useful. The only access methods allowed are VSAM, Media Manager, and STARTIO.
Other services are not available in SRB mode, such as ENQ. Therefore, code services need to be broken out from logic, and services need to be able to run in TCB or SRB mode. For example, ENQs can be replaced with latches. This means that QNAMEs and RNAMEs must be converted or interpreted to a latch number. It also means that they must release latches when percolating (write own RESMGR).
NEON Enterprise software, CA, DataDirect, SyncSort, and many other vendors now exploit support for zIIP processors. NEON’s Eclipse IMS utilities allow off-loading of up to 98% to zIIP.
If you’re interested, a copy of Tom’s presentation is available for download from the Virtual IMS Connection Web site at www.virtualims.com/presentations/specialtyproc.pdf.
And this presentation ties in nicely with an announcement back in May from DataDirect Technologies (part of Progress Software). They announced the results of internal benchmark testing performed at the company’s mainframe development lab. These test results found examples where greater than 99 percent of mainframe Web services-related processing could be diverted to a zIIP specialty engine using DataDirect’s Shadow software.
Shadow Version 7 is a single, unified platform built exclusively for integration with System z mainframes. It expands the utilization of the zIIP specialty engine to more workloads than just DB2, including the non-relational mainframe databases Adabas, IMS/DB, IDMS, and VSAM, as well SOAP/XML parsing necessary for creating Web services within the mainframe to applications residing within CICS, IMS/TM, IDMS, and Natural. Shadow provides a way for the processing associated with SOA integration and data queries to be diverted from the mainframe’s General Purpose Processor (GPP) to the zIIP specialty engine – which does the work without using any of the mainframe licensed MIPS capacity.
Exploitation of the zIIP processor enables organizations to cost-effectively integrate the mainframe into an SOA by conserving GPP MIPS usage, slowing the rate of MIPS consumption and deferring costly mainframe capacity upgrades – the company claims. And I’m sure that’s the real point – that the specialty engine doesn’t save too much by itself, it’s the fact that a hugely-expensive mainframe upgrade can be postponed that makes it such a strategic purchase for organizations.
The complete mainframe TCO benchmark test results are included in the whitepaper “Lowering Mainframe TCO Through zIIP Specialty Engine Exploitation” at www.datadirect.com/downloads/main-registration-form/mainregform/index.ssp?atc=DDT_Shadow_Whitepaper_zIIPBenchmarks.
On top of that, a survey conducted for CA by TheInfoPro found that 93% of respondents projected that their use of the IFL (Integrated Facility for Linux) specialty processor would increase or at least remain steady over the course of the next two years. 42% projected that their use of the IFL would grow between 21% and 40%, and 10% projected that it would grow more than 76%.
The two main reasons cited by respondents for this increased use of Linux on the mainframe were the desire to take advantage of computing capacity available on their mainframe’s central processors and/or IFLs, and their assessment that using Linux on the mainframe would be more cost-effective than other platforms.
Complete survey results from the study are available at ca.com/mainframe/linuxresearch.
No comments:
Post a Comment