isham research
IBM's zSeries Application Assist Processor for the z990 and z890 presented a new way of lowering mainframe software costs. The feature was also carried forward to the z9 109.
The concept of "offload engines" is old - for many years there were rumours (especially when IBM was competing with Amdahl and Hitachi) that significant DB2 functionality would be hived off into special purpose database processors. Now, it seems, such a feature - a zIIP - is imminent.
There's no doubting DB2's pedigree as a database:
DB2 is the most respectable and most powerful database engine in the world: it’s the pinnacle of database development. IBM makes a claim (undisputed to my knowledge) that more structured data is stored in DB2 than in any other database engine.
Certainly, according to the Winter Corporation’s 2005 survey, the largest OLTP (On-Line Transaction Processing) databases in the world are hosted on DB2. The volume prize goes to the Land Registry at 23.1 TB and the prize for the number of rows goes to UPS – 89.6 billion; both run on DB2.
The Register, 18 January 2006
A few days before, out of nowhere, a piece appeared in Linux Insider:
By bundling Oracle's database on its higher-end servers, Sun is trying to stem its losses in this space, which have been mainly to IBM's DB2. "Sun does better in the lower end," King said. Some of those losses have been due to costs, but IBM's superior performance has been another factor.
"IBM has set benchmark after benchmark, and Sun has had trouble keeping up," King said. "They needed to find a way to keep their existing customers. The way to do that is either increase your bells and whistles or cut costs. Sun opted to add the bells and whistles."
Linux Insider, 12 January 2006
But all of these records have been set on pSeries hardware.
And even more surprisingly, a very thinly-veiled preannouncement from an IBM executive in the Enterprise Systems Journal:
"Does IBM plan to introduce zAAP-like engines for traditional COBOL applications?"
"It’s possible, [Collette] Martin says. 'COBOL applications typically are seen in terms of data-serving types of workloads and back-end types of processing, so if we looked at it, we wouldn’t necessarily look at COBOL per se, but we would look at in terms of database connectivity and such,' she indicates."
Enterprise Systems Journal, 17 January 2006
Three DB2-based articles in four days instead of the usual four months?
So the DB2 offload processor - a zSeries Integrated Information Processor or zIIP - looks like it will be with us in 2006. Obviously it will be announced for the current top of the range, the z9 - but also as an end-of-life kicker for the z890, whose successor is due in 2Q06?
A zIIP, by hiding enclave SRB DB2 execution cycles from the software charging regime, would reduce (improve) the price/performance of a zSeries-z/OS-DB2 package. But why?
Because zSeries is suffering. It has several fierce competitors, and one of its real problems is that two of them carry IBM badges - the iSeries and the pSeries. The old, comfortable view that the large mainframe was at once the biggest, most secure and most reliable of these platforms is largely no longer true, and zSeries frequently finds itself losing out to its IBM stablemates - especially in large new opportunities with, e.g., web-serving content.
So this initiative should perhaps been seen as emanating from the zSeries product house rather than from Software Group. Much will depend on the Ts&Cs - will there be any charge at all for DB2 on a zIIP - what will zIIPs cost, and will they be transferable to future systems, as can be done with IFLs?
The announcement is certainly imminent - decisions on financial viability may be some way off.
IBM's database competitors, such as Oracle, will also be given food for thought. Since none control a hardware platform, this type of synergy is not available to them.
And a footnote. DB2's reliability and availability are justly respected, but unfortunately IBM's software license Ts&Cs aren't up to the job:
"If you plan carefully, you can ensure DB2 does not run in both LPARA and LPARB during any intervals. That is, bring DB2 down in LPARA during hour X and then wait until hour Y to bring DB2 up in LPARB. If you run DB2 in both LPARA and LPARB for some intervals during the migration, then SCRT will consider for the combined rolling 4 hour average of LPARs A and B during those intervals where the overlap occurs."
Sub-Capacity Corner on the IBM web site
So whereas logic (and technology) would suggest overlapping to avoid a break in service, software charging forces you to take a service hit.