Anyone paying attention to the Sine Nomine demo, two weeks ago, now knows that Solaris is inevitably coming to System z. In the wake of all of this, I have heard from a number of you – and people throughout the industry about – you guessed it: “What’s next, Windows?” I’m guessing many of you have the same question. To really get at the dynamics of this, we have to look to the past. Back in the early 90’s, Windows was not just on the x86 architecture (at the time, only on Intel – remember Wintel?). It was also running on MIPS, Alpha and the PowerPC architecture. There’s something a bit different about the x86 architecture….this is a bit technical here, but it uses the Little Endian bit representation within a byte while the RISC architectures under the popular UNIX platforms and IBM’s mainframe use Big Endian architecture. Solaris and Linux were written in a way that makes that bit representation transparent. But Microsoft decided long ago that Windows would only run in Little Endian mode. Back in 1994, there was a skunk works within the IBM mainframe division that looked at running Windows NT as a native operating system on what was then a 10-way S/390 platform. It figured out how to boot the machine up as a Little Endian server and it could have run Windows across those 10 processors. But guess what? No hypervisor or virtualization capabilities would exist. They have been written in Big Endian mode. So it would be an entire mainframe dedicated to a single instance of Windows. My palm can do that. So, IBM realized then that this had no future in terms of consolidation value. In turn, Microsoft decided to uniquely support the x86 architecture and the Alpha and MIPS implementations of Windows died a rather quick death.
Next up was to bring some Windows portability to the mainframe. So working with Bristol Technology (now a subsidiary of HP), IBM looked at getting a set of Windows 32 bit APIs and its OLE and COM capabilities on OS/390. This was just after IBM had announced its intention to brand OS/390 as a UNIX operating system. Bristol Technology had a license to the Microsoft source code to facilitate that. Well, Microsoft must have gotten afraid of the possibilities of Windows applications running easily on the mainframe, so they took away the software license from
. Bristol, in turn, sued them for unfair trade and they won. But by then, Microsoft’s approach had driven these types of developers from their platform. Today, Mainsoft Corporation provides a Windows portability layer across UNIX systems and z/OS, but we’ll never see a day when Windows will run natively on the mainframe.
So what are the implications to the mainframe? Let’s start with development tools for creating new applications. If you only use Microsoft .Net development tooling, those solutions will be relegated to the Wintel platform. Should those applications want to interoperate with the mainframe, there are a variety of connectors that enable interoperability with both 3270 and SOAP/Web service based applications as well as distributed data requests. As mentioned earlier, you can use Mainsoft’s technology to translate the .Net code into Java byte codes and run that on z/OS and Linux for System z as well. Therefore you get some developers synergy, but deployment options beyond Wintel platforms.
If you really want cross platform deployment from the Windows desktop environment, eclipse.org is an open standards group comprised of a number of leading tooling vendors to facilitate rapid application development, good tool integration and provide a flexible choice for platforms to which those applications can be deployed. Leveraging this tool set will facilitate exploitation of mainframe technology and is highly recommended to deliver the best qualities of service for software running on System z. IBM’s Rational Developer for z is an implementation of the eclipse capabilities for System z.