isham research

The z900's successor - why is IBM now so reticent?

Sometime in 2003 - probably in mid-May - IBM will announce a new zSeries mainframe; the eventual successor to the z900. This system was described in early 2002 to all who would listen - an outline of its layout and performance was hosted on several German web sites for some months - but IBM has recently become remarkably coy about it.

Other code names have been used in public and continue to be used inside IBM, but this discussion will use the term "G8".

So why is IBM suddenly so reticent? In the past, IBM systems were announced up to two years before availability - during the PCM era lead times were shortened both to obtain competitive advantage and to avoid accusations of market freezing. Even now, the company is prepared to discuss POWER5 over a year ahead of shipment. But in early 2002, IBM's failure to prepare the market for the Linux-only z800 cost it three to six months of mindshare generation and significantly deferred revenues from the product - with no competitive justification for such secrecy. A year on, IBM has sold over a thousand z800s - but despite the press release, very few have been Linux-only systems.

IBM's mainframe competition today is vastly more dangerous than Amdahl or Hitachi ever were - if the old-style PCMs won a deal IBM still received the same software revenues and could easily displace the PCM system in its turn. Today, a mainframe customer lost to Sun or Hewlett Packard today is lost forever. IBM's reluctance to publish a credible roadmap for its most important users is thus somewhat perverse - though doubtless welcome in Santa Clara and Palo Alto.

This blackout may have repercussions. Although G8 uses a lot of z900 technology, it is sufficiently different to require some investment in positioning - configuration and infrastructure - for effective exploitation. Ideally, potential users should have made appropriate provisions in their 2003 IT budgets - but it seems that most IBM non-disclosure briefings have been made at higher management levels and not to the technical staff who would realise the requirement.

G8 is important - in various forms it will be the "current" IBM zSeries mainframe for three years or more. The release of z/OS expected in September 2004 will not execute on G5/G6 processors. Generation skipping is no longer an option - all large users who stay with the zSeries platform will eventually adopt G8. Fierce cost-cutting within IBM has reduced the resources available to deliver its functionality, thus extending lead times for many features. Five years from now IBM's autonomous computing initiative will have seriously eroded zSeries' main differentiators. Many long term initiatives at IBM don't mention the mainframe at all.

Although the current z900 supports a 16-way z/OS image, most users prefer multiple systems, each with fewer processors. With Parallel Sysplex support now mature, users can achieve higher availablity and greater flexibility by spreading resources across multiple systems.

In early documentation G8's uniprocessor performance was estimated as 1200MHz - compared with the z900's 800MHz - or about 440 MIPS. But it's a superscalar machine, and thus likely to offer a proportionately greater boost for the 'new' applications ported from the *nix world - some of which perform poorly on the current zSeries.

There are, however, users who need large images - and some of these users anticipate needing more than the Moore's Law performance improvement that G8 will offer. So the time has come to tackle the 16-engine barrier.

As so far described, a fully configured G8 will consist of four multi-chip modules (MCMs) each carrying eight chips - each MCM will function as a "node". Ultimately, all of the 32 chips will be twin-cored for a maximum of 64 physical processors. This layout enables a number of design points to be reached economically - though whether IBM will actually do this, and at what points in the product life, is not yet clear. A z800 replacement using a single MCM is a distinct possibility in 3Q 2004. To what extent the internal structure will be visible to users also remains to be seen - IBM has publicly espoused the concept of self-managing systems so it is likely that G8 will be self-configuring, allowing the user little control over LPAR disposition.

Every IBM system since 370/XA has been limited to a maximum of 256 channels by the architecture. Without FICON (and in a few cases even with it - a z900 has a maximum of 96 FICON channels) this would already be a serious constraint. So G8 needs to break the 256-channel limit as well. This limit is deeply ingrained not only in operating system software but also in mushware and may be hard to change radically at first. It seems likely that z/OS itself will never support more than 256 CHPIDs and 16 logical processors - "Sysplex in a Box" offers more linear scalability and better resilience than a single huge z/OS image, and also avoids the cost of a truly massive software re-engineering effort. z/VM, of course, will have to support the entire physical system.

The z900 announcement stated specifically that it would be the last system to support parallel channels. In essence, the G8 will probably ship with four separate channel subsystems or groups, each a close relative of the existing 256 channel z900 system - giving a system maximum of 1024 channels.

Exploiting these to the full - Intelligent Resource Director control of all 1024 with no node dependencies - could take some time. The existing z900's Dynamic Channel Path Management can reassign switched ESCON channels to meet variations in load - this functionality will be of greater benefit on the G8 - users should start planning for this channel configuration as soon as possible.

There is need, also, for a greater degree of influence over processor assignment than is needed or provided in the current zSeries. The first issue revolves around the selection of processors to support a large LPAR. In the current z800 and z900, the processors withint each system are identical - but in G8 their position within the system has significance. Hot sparing takes place only within a node because that is the unit quiesced by microcode in the event of a processor failure - so if a high-availability LPAR spans nodes (a "horizontal LPAR") it must have spares available in all the nodes in which it has processors.

A small LPAR may be contained entirely within a single node (a "vertical LPAR") but even here there is a theoretical difference caused by G8's use of twin-core chips. Such a chip - already used in IBM's pSeries and iSeries - has two processors per physical chip. If the failure occurs in some common function, both processors will be lost - and therefore the second processor on a chip is a poor candidate as a hot spare for the first. There are two ways to lay out a small LPAR within a single node - a "thin vertical LPAR" uses no more than one processor from any chip for optimum availability, and a "thick vertical LPAR" may use both.

Although a 64-way has been described, it is certain that it will be neither available nor needed at first. Or indeed if ever - 9,000 MIPS is a lot of compute power. z/OS support for more than 16 engines seems to have been cancelled - probably partly because of critical underfunding of development. Yields of fully-functional twin-core chips may be also be low at first and 12-processor MCMs using a mixture of twin-core and single-core chips may be employed in early models.

At first sight this seems like heaven - all those processors. In fact, a G8 strongly resembles four z900s in a single box - but with only 16 physical processors per node instead of 20. The 'missing' four are significant - in the z900 three are used for SAPs and one is a spare, but in the G8 the SAPs and spares are taken from the 16. So an early G8 will only have 8 processors available per node - with performance roughly equal to a 16-way z900 non-turbo - and a late one having 12. This is before Coupling Facilities - with one Coupling Facility per node, only seven processors would available for LPARs in the early nodes. The majority of production LPARs will therefore be 'horizontal' - a 16-way would be a three-node LPAR.

The first systems will in fact be two-node systems with only 8 processors available per node - a 16-way perhaps 30% more powerful than the existing z900. It remains to be seen if such a small performance increment will be incentive enough for swap-outs; especially given the functionality and maturity of Parallel Sysplex management.

Some confusion also remains over IBM's System-Managed Coupling Facility Structure Duplexing feature, announced for z/OS 1.2 in February 2001 for 4Q01, re-announced in June 2002 for 4Q02 - a slip of one year - and now rumoured to be expected at the end of 2003. The only reason zSeries can command the price premium that it does over other architectures is its reliability and availability leadership - delays such as this erode this advantage and possibly delay other products - especially middleware - that have been designed with the feature as a prequisite. IBM had a similar slippage with the IBM License Manager and maintained right to the cancellation of the project that it intended to carry through with it - a precedent not comforting to those waiting for System-Managed Coupling Facility Duplexing. When (or if) it arrives, the feature will require participating Coupling Facilities to have Coupling Links between them.

So far, this discussion makes no all mention of Integrated Facilities for Linux - IFLs. With over 600 mainframe users already evaluating or using Linux/390 and perhaps 25% of the MIPS to be shipped in 2003 supporting Linux/390 workloads, this is obviously unsatisfactory and will be corrected in due course. IFLs, of course, further reduce the number of engines available for z/OS workloads.

An LPAR using engines in multiple nodes may suffer a performance impact - the more nodes, the bigger the impact - because each node has its own level 2 cache. An LPAR crossing four nodes is likely to experience additional impact because each node can only see its immediate neighbours - communication with the "most distant" node is via one of the others. LPARs could also change dynamically if the Intelligent Resource Director (IRD) decides to add an engine from another node into an otherwise 'vertical' LPAR. The performance implications are likely to be highly workload-dependent - although automation is likely to bias LPAR configurations towards a 'best-case' configuration, the potential downside for getting it wrong could be the loss of a thousand or more MIPS.

Although it was possible in the recent past to maintain at least some pretence that performance measurements were accurate and repeatable, all such ideas will have to be dropped with G8.

Software charging may prove complicated, and this is perhaps part of the reason that the IBM License Manager was abandoned. There are official tables for the MSUs delivered by a z800 depending on its configuration - but such tables for G8 would have to be multi-dimensional. The zSeries is now the only significant platform unsupported by price/performance benchmarks. Although IBM may produce LSPR measurements - probably with superscalar content - these are now of little or no use; the compatibles against whom they were chiefly used are gone from the scene and LSPR presentation contains no price/performance element.

Overall, G8 presents some novelties. Its significantly improved uniprocessor performance and the 3.2-fold increase in the number of engines provides significant scope for growth. But there's another train on the same track, gathering speed approaching - the maturity of IBM's Parallel Sysplex concept. Many users are already wondering whether their requirements will push them to G8 - or whether they can exploit already depreciated (and therefore more economical) z900 hardware for much longer than planned.

There are no universally valid approaches to exploitation of G8. This - and the absence of a plug-compatible competitive threat makes IBM's refusal to prepare the market perverse. In the meantime, Sun and HP are making the most of the uncertainty.

And finally:

"We should cut the price of hardware ASAP, simplify software pricing, focus development on simplification, implement a hard-hitting communication programme to reposition the mainframe and workstations, and underscore that the mainframe is an important part of the CIO's information portfolio."

Dick (Rich) Gerstner's 1993 advice to his elder brother
"Who says elephants can't dance?", Lou Gerstner, page 34

"Raptor" (the z800) and "T-Rex" (the real IBM Internal Use Only codename for the G8 - it's actually someone else's trademark) seem curious choices of code names for products that some are already too eager to dismiss as dinosaurs. Quite why IBM's crack marketing team hands chances like this to its competitors is unclear - but then a lot of IBM's mainframe marketing makes little sense these days. T-Rex is not only an extinct egg-laying lizard with most of its brains in its butt, but it's also confusingly the code name used by NEC for a 64-bit MIPS processor. G8 was originally named after Galileo - a genius who stood up against fashion and changed the way the world thought - the kind of help mainframes could do with at present. Was it dropped because both he and Copernicus thought the Sun to be the centre of our universe? The final product name is likely to be something like z950 or z990.

Older articles are in the archive

The press's view of isham research is here

24-hour telephone, SMS and email responses are available for clients.

To email Phil Payne: click here.