isham research
After over a year of fleeting kimono-openings, IBM has finally announced its long-awaited z990. The final product is in some ways what was expected, but in other ways presents surprises.
This blackout may have repercussions. Although the z990 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 many IBM non-disclosure briefings have been made at higher management levels and not to the technical staff who would realise the requirement.
The z990 is important - in various forms it will be the "current" IBM mainframe for much longer than any of its predecessors. Generation skipping is no longer an option - all medium and large users who stay with the zSeries platform will eventually adopt the z990. Release 1.6 z/OS - expected in September 2004 - will not execute on G5/G6/Multiprise 3000 processors, although IBM has extended support of z/OS 1.5 to 1Q07.
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 z990's uniprocessor performance was estimated as 1200MHz - compared with the z900's 800MHz - or about 450 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 need more than the 45% or so improvement that z990 will offer over the 2064-2xx. So the time has come to tackle the 16-engine barrier.
As so far described, a fully configured z990 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[1]. 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[2]. 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 z990 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 z990 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. Although z/OS itself will 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. The z990 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 z990 - 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 within each system are identical - but in z990 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 z990'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,060 MIPS is a lot of compute power. z/OS support for more than 16 engines will not be available until z/OS 1.6 in September 2004.
At first sight this seems like heaven - all those processors. In fact, a z990 strongly resembles four z900s in a single box - but with only 12 physical processors per node instead of 20. The 'missing' ones are significant - in the z900 three are used for SAPs and one is a spare, but in the z990 the SAPs and spares are taken from the 12. So a z990 will only have 8 processors available per node - with performance roughly equal to a 16-way z900 non-turbo. This is before Coupling Facilities - with one Coupling Facility per node, only seven processors would available for LPARs. 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 45% 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.
The 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 - was largely cleared up in advance of the z990 announcement. But the delay was damaging. 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.
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 z990.
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 z990 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, the z990 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 the z990 - or whether they can exploit already depreciated (and therefore more economical) z900 hardware for much longer than planned.
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