z/OS Version 1.7 is coming out September 30, with z/VM Version 5.2 generally available December 16 and z/OS.e Version 1.7 available September 30 as well.
Because IBM mainframe shops are loathe to change their operating system levels unless they really, really have to or they find some new feature absolutely compelling, the new Danu System z9 mainframes do not require customers to move to the latest versions of any of this operating system software.
The reason why mainframe applications are exceedingly layered and complex, and many mainframe shops are not exactly sure how some of their applications – which have roots going back decades – are coded and what dependencies they have. With the 64-bit Freeway zSeries 900 mainframes in late 2000, IBM had no choice but to force customers to move to z/OS 1.4, its first 64-bit mainframe operating system because the Freeways had the first 64-bit mainframe processors IBM ever delivered.
But customers that have made that jump – and it was pretty substantial – do not have to keep jumping up releases to move to newer hardware, even though they might want to and IBM certainly wants them to.
That said, IBM is telling mainframe shops the combination of the new System z9s and z/OS V1.7 can deliver bandwidth, throughput performance, diagnostics, and other improvements that the hardware alone cannot deliver.
Presumably, some of these improvements in the z/OS V1.7 code will also manifest themselves on prior Freeway zSeries 800 and 900, Ptero zSeries 890, and T-Rex zSeries 990 systems. While z/OS V1.7 has a lot of goodies, what the V1.7 announcement is also significant for is the promises that IBM is making.
First the goodies, then the promises.
Content from our partners
z/OS V1.7 is noteworthy primarily because it allows a single system image to span up to 32 processors, which on the System z9 means just under 12,000 MIPS of processing power using the new MI MIPS scale. The prior z/OS V1.6 that debuted in late September 2004 only scaled to 24 processors in a single system image on the zSeries 990, which meant that the biggest image a customer could have on the T-Rex box was just under 7,100 MIPS.
The faster 1.7 GHz z9 processors used in the System z9s coupled to the scalability improvements mean customers can bring about 70 percent more performance to bear on a single, big workload. IBM had promised to deliver a version of z/OS V1.6 this year that spanned 32 processors, but decided to kick out the System z9s and z/OS V1.7 instead.
The z/OS V1.7 operating system also has 64-bit VSAM record-level sharing support. The TCP/IP HyperSockets interfaces now support the IPv6 protocol in addition to the pervasive IPv4 protocol. This IPv6 support can be used to link z/OS and Linux partitions running on mainframes. At some point, the Internet and intranets will go IPv6, and the odds favor mainframe shops taking the plunge first, as they often do in production environments.
Perhaps most significantly, z/OS V1.7 has support for multiple subchannel sets, which is necessary given the fact that mainframe I/O subsystems are based on 64KB unit control blocks. If IBM didn’t add a second set of subchannels and support for Parallel Access Volumes on those subchannels to mirror data, all of those MIPS in the System z9 might go up the chimney, waiting for data.
Prior zSeries servers had a maximum of 1,024 subchannels and 64,512 devices, while the System z9 has an additional 768 subchannels per logical partition yielding, up to 65,280 devices per partition.
IBM also made a bunch of statements of direction when it rolled out the z/OS V1.7 announcement. It says z/OS V1.7 can scale from 1 to 32 processors in a single system image with good scalability, by which IBM vaguely says good is based on internal lab measurements. If you do the math based on the LSPR relative performance benchmarks, about 35% of the aggregate MIPS in a 32-processor System z9 goes up the chimney, which is about what you expect for a big SMP box.
But this is not IBM’s most efficient box when it comes to scalability. Based on its rPerf relative performance benchmark (which is loosely based on the TPC-C online transaction processing benchmark), a p5 590 Squadron server using 32 of IBM’s 1.65 GHz Power5 processors has about 79 percent efficiency, which means that only 21 percent of the aggregate oomph in the machine is wasted by the SMP clustering. The i5 product line shows essentially the same scalability, which just goes to show you how hard it is to extend an architecture that is four decades old.
However, IBM did not offer a box with 54 active engines (which the System z9 has) just so mainframe shops with one big z/OS partition could have a bunch of Linux partitions running side by side with a machine with maybe 36, or 40, or 48 processors in a single z/OS image. IBM wants customers to be able to do this, of course, but it also undoubtedly wants to span to the full 54 processors for those z/OS customers who need it. Some mainframe shops will want to have all 54 of the engines in the System z9 running z/OS V1.7 and perhaps a DB2 database and the CICS transaction processing middleware.
They may be able to get rid of Parallel Sysplex for their mainframe workloads and go back to clustering only for high availability. As efficient as Parallel Sysplex might be, it is not, by its very nature, as efficient as a big SMP box for supporting a workload. In any event, IBM says it will support single system images in a single logical partition that spans more than 32 processors at some point in the future.
If it can get z/OS to span the full 17,800 MIPS in a fully loaded Danu box, this would represent a big jump in single system image size. The fact that IBM is not specifying how far it can take scalability on a single z/OS instance tells me the company is not sure what it can do yet. But if Big Blue is capable of pulling it off, the single system image size would have grown by a factor of 2.5 from the T-Rex to the Danu machines.
IBM also said it would, in the second half of 2006, announce a tweaked version of the New Application License Charge (NALC) that would offer sub-processor pricing, which would deliver improved price/performance on new workload environments – meaning, anything that is not a legacy mainframe workload based on CICS, VSAM, and so forth and use the 3270 green-screen protocol.
Speaking of VSAM, IBM says it will have to push out the delivery of the VSAM Java Data Base Connector (VSAM JDBC) that IBM said last August it would deliver with z/OS V1.7. IBM is not saying when VSAM JDBC will be available, but the company says it will not be out in 2005.
This facility will allow distributed programs, written for other platforms in Java as well as on the mainframe itself, to read and write VSAM data and not have to use a copy of the VSAM data; VSAM JDBC will also work in conjunction with DFSMS Transactional VSAM Services (DFSMStvs, and yes, that is a nested acronym) to allow Java applications running in IBM’s WebSphere middleware to participate with legacy code in coordinated commit processing.
