Exclusive Interview with 

Ron Higgin  

Director, Product Management  
Platform Solutions, Inc. 
 

Platform Solutions, Inc. (PSI), is the first developer of a new generation of mainframe computers compatible with the broadest set of datacenter environments and operating systems, including IBM's z/OS.

Gene Amdahl, the undisputed father of IBM S/3xx class mainframes, and now a founding member of the PSI Advisory Committee, has this to say about what PSI brings to the table: "It is exciting to me, personally, to see the efforts begun at Amdahl Corporation nearly 35 years ago to deliver a meaningful choice to the mainframe marketplace being continued by PSI.” 

Ron Higgin of PSI gives us an exclusive, in-depth look at this exciting offering, the first alternative to IBM mainframes in nearly a decade -- in this interview with Anura Guruge, IT In-Depth's editor at large.

Ron Higgin: a synopsis

Ron Higgin has over 36 years of experience working with enterprise class computing systems.
Most of his career has been dedicated to the design and development of enterprise scale
software systems and products.

Ron was employed by Boole & Babbage from 1981 until its acquisition by BMC Software in March
of 1999. During his 18 years with Boole he held several senior technical management positions including Director of Interactive Systems, Senior Technical Staff to the VP of Engineering, and Senior Scientist in the research and development organization. More recently he served as BMC Software’s Director of Technology Planning and CTO of the MAINVIEW business unit until the
Spring of 2005.  Ron is currently serving as Senior Product Strategist for Platform Solutions, Inc.

Ron is a frequent speaker at conferences and other professional gatherings. He has published numerous papers on a wide range of topics pertinent to users of large IBM computing systems. Ron is also a past President of the GUIDE International user group, of which he was a member for 27 years. He has been active in the SHARE user group since the dissolution of GUIDE in 1999.

Q1: Ron, to set the background for our readers (and to definitely pique the interest of some of our BIG Iron Club members) as well as to give you folks some vicarious, but instant credibility, can you please tell us, at a relatively high-level, how PSI and its core technology evolved from what the Amdahl Corporation was doing … and how this all came to be in terms of time-line, people and funding?

A1: In 1995 a team of Amdahl engineers collaborated with Intel Corporation on the system design of Intel's new 64-bit IA-64 microprocessor architecture with the intent of exploiting off-the-shelf processor chips to build a new generation of IBM-compatible mainframe systems. In late 1999 a group of engineers gained intellectual property rights to this work.  In September of 2003, PSI received its first round of venture funding to commercialize the technology with the aim to develop and deliver a new generation of mainframe systems -- systems capable of bridging the technology gap between the mainframe and open systems world.

      Today PSI is in the early stages of rolling out its first generation of Intel Itanium-2 based mainframe systems.  The company is well funded by a prestigious set of investors that now includes Blueprint Ventures, Goldman Sachs, Intel Capital, InterWest Partners, and Investcorp.

Q2: Ron, can you elaborate on PSI’s raison d’etre and how PSI intends to set about fulfilling its goals vis-à-vis large data center computing?

A2: PSI’s primary mission is to deliver highly scalable and cost effective mainframe class servers that offer customers unprecedented choice with respect to application hosting.  These machines – based on off-the-shelf processor chips -- offer customers the option of hosting open systems based application environments such as Windows and Linux on the same physical server as traditional mainframe systems such as z/OS and VSE.

      Besides its scalability, the PSI server platform features extensive and flexible configuration options that can be exploited to satisfy a broad range of customer use cases. Amongst such uses are:

Q3: Ron, what are the motivational factors for an enterprise class customer to go with your approach … is it just cost, price/performance, RAS, support or some synergistic combination of some or all of the above?

A3: Certainly cost is a major component of our customer value proposition.  Beyond the obvious and substantial cost savings that result from exploitation of off-the-shelf chip technology customers deploying our servers can achieve a number of more direct savings that impact their overall total cost of ownership (TCO).

      Customers can exploit the advanced multi-level partitioning capabilities of our servers to lower their overall mainframe costs and more flexibly manage software costs. Similar to Amdahl’s Multiple Server Facility (MSF) PSI will offer fixed capacity virtual CECs, each with their own unique serial number. This option (when ordered by a customer) enables a customer to license many software products based on the capacity of the virtual CEC in which the products are used rather than the total capacity represented by the physical server.

      Additionally many customers will be able to lower their TCO by leveraging the unique ability of our server platform to simultaneously host (for example) multiple Windows and z/OS-based server systems. These savings are achieved through a variety of means such as reduced consumption of physical resources (electric power, cooling, floor space, cabling, etc.) and operational simplification.

      All of this is good.  As I just pointed out, consolidating multiple host systems (of like or unlike kind) on the same physical server offers tangible customer value in the form of reduced TCO. But we need to look beyond this “bare bones” consolidation/migration model to one where significant additional customer value is realized through synergy resulting from the fact that these multiple disparate systems are co-located on the same physical server.  But that’s a discussion for another day.

Q4: Ron, I have seen the abstract for the “Mainframe Integration – Don’t Stop at Linux” session that PSI will be presenting at the next SHARE.  I have a two-part question related to that, in particular the emphasis on Linux. The abstract starts off by implying that having an OS from the distributed world [in this case Linux] and “MVS” [in this case z/OS] running on the same hardware platform [i.e. a mainframe] is somewhat exceptional.  But haven’t we, and especially Amdahl, had Unix, or at least Unix services, alongside MVS since the mid-1980s and why does PSI now consider the Linux capability to be that much more different?  That was part one and leads me to this follow on question.  Is there some implicit Linux emphasis to your solution set – in other words, are you kind of trying to say that your solution is primarily of interest to customers that intend to run some level of Linux workloads alongside IBM OS LPARs, as opposed to those that, as yet, only have traditional “MVS”, VSE or VM workloads?

A4: Wow! You read far more into that abstract than I was attempting to communicate when I wrote it.  Be that as it may you have certainly raised some well misunderstood issues that need to be discussed.

      Let’s start with the Unix issue.  It is certainly true that there have been several mainframe instantiations of Unix. To the best of my knowledge all of these implementations were proprietary to their respective vendors. And of course all of these Unix offerings were created by porting some variant of the Unix base to execute run on the mainframe instruction set. Such Unix ports involved writing customized code to adapt the system to the mainframe architecture.

      More often than not these ported systems did not run as well on the mainframe as on their native hardware platforms.  There are a lot of reasons for this beginning with the fact that the EBCDIC character set is the native encoding for the mainframe whereas ASCII is native encoding for almost all other hardware platforms. Indeed IBM had to address this issue when they introduced Unix to the z/OS (actually at the time it was MVS/ESA) environment in the form of “OpenEdition” -- later renamed to Unix System Services, or USS for short.

      USS is quite different from the Unix ports of the past.  First, USS is not a port at all. It is essentially a z/OS specific implementation of set of Unix compliant programming interfaces (APIs) that allow one to execute a program written to these APIs within a z/OS address space. IBM does provide custom ports of selected Unix shells and utilities but the actual Unix system (from a kernel perspective) was written from the ground up. This was done so that Unix-based application programs and utilities could run side-by-side with traditional mainframe workloads within the same z/OS system image. A conventional Unix kernel port would not have provided this capability.

      So you can see the industry in general and IBM in particular have been trying to address this Unix-mainframe application cohabitation problem for at least a couple of decades.  Software vendors and customers who attempted to port Unix code to run under USS quickly discovered such ports involved more than simply recompiling and re-linking the code. In fact the vast majority of customers and those in the ISV community gave up on the idea of porting code to USS a long time ago. It’s just too hard.

      Linux has most of the same compatibility and co-hosting problems as Unix. In fact the only real difference between Linux and other Unix-based systems is that so far Linux has avoided the fragmentation problem that plagued Unix. Loosely translated this means you can write a program to the standard Linux APIs and port it to any hardware platform (for which a Linux port is available) with a simple re-compile and re-link.

      Getting back to the mainframe, IBM learned from their prior Unix porting and USS experiences. This time they decided to leverage the work of the Open Source community and simply adapt (working within the Linux architecture) the kernel to run as optimally as possible on the native mainframe hardware. But for many workloads this optimal performance is not good enough. Often these workloads will execute orders of magnitude slower under mainframe Linux than on, for example, an Intel-based hardware platform.

      PSI servers offer customers the best of both worlds.  Of course they can choose to run mainframe Linux on our machines.  But they also have the option of running it on the base Intel Itanium hardware on the same physical box that is hosting traditional mainframe systems such as z/OS. This is what is really new.  It’s all about giving the customer the choice of mixing and matching hardware and software that satisfies their business requirements.

      Unlike other mainframes PSI servers are capable of extending this “native execution” concept to other “open” operating environments such as Windows.  Indeed a customer can co-host any Itanium supported operating system on the same physical box as is hosting traditional mainframe workloads.  I’d say that qualifies as something new and exciting!

      The bottom line is PSI servers are designed to facilitate customer choice. A customer can choose to use one of our servers to concurrently host one or more mainframe operating environments (z/OS, VSE, etc.) in any combination they desire. At the same time and on the same physical server they can choose to host “open systems” environments (Linux, Windows, etc.) on the native Intel Itanium hardware.

Q5: Ron, I understand that you folks are hesitant to ‘fully open the kimono’ (so to speak) when it comes to technical disclosure, but can you tell me, because I am mighty curious (and I know that many of our readership will be too) whether you actually set out to emulate the various non-CP PUs available on contemporary IBM mainframes and I was thinking in particular SAPs, ICFs and IFLs – and I do appreciate that the zAAP is rather specialized (and as yet not widely used)?

A5: Yes and no.  The internal architecture of our servers is similar to IBM’s in that we employ SAP engines to perform all I/O and processor service functions.  I can tell you – without going into the gory details – our implementation of the SAP functionality is quite different than IBM’s.

      As far as ICF (Internal Coupling Facility), IFL (Integrated Facility for Linux), zAAP (Application Assist Processor), and zIIP (Integrated Information Processor) engines are concerned, we certainly did not set out to offer similar execution personalities/profiles for the engines that comprise our servers.  In fact we did not even view IFL engines as being desirable since our systems allow a customer to run Linux built for the native Itanium hardware (instruction set) in one or more physical partitions while one or more z/OS systems (for example) concurrently execute in another physical partition.

      It is generally accepted by even the most hard core mainframe bigots that Linux runs more efficiently (faster) on open systems hardware engines than it does on the mainframe.  So (at least in the beginning) we never envisioned a customer would want to run Linux in one of our mainframe partitions. Recently we have seen some viable use cases for mainframe Linux that have caused us to reconsider our position on this subject. However I’m not prepared to discuss this in any further detail at this time.

Q6: Ron, this is my last question, and yet again I appreciate that I (as is my wont) is getting rather technical and specific.  But I am really curious because I am into the whole PUs per machine thing (as you can see in my debate with IBM as to the number of PUs in a MCM).  What intrigues me, and you can (as we say) ‘weasel word’ around this, but does one Itanium 2 processor have to equate to one CP (or PU), relative to the IBM OS, or can you folks, using the magic in your micro-code, use multiple Itaniums to emulate a single PU?

A6: One of the industry’s hot buttons right now is virtualization.  Long ago storage vendors disconnected the notion of a spinning DASD disk (or tape) from the actual physical device (and indeed physical media) on which the data is stored.  For example, the storage represented by a DASD device as a customer perceives it might be physically stored across an array of real disk devices whose physical geometry bears no resemblance at all to that of the perceived (emulated) device.

      One of the key value propositions of storage virtualization is that the underlying physical storage devices, media, and storage subsystem implementation can be updated or replaced to take advantage of new technologies completely transparent to the programs that use those devices. This transparency concept clearly has value in contexts other than storage.

      It would be fair to say that PSI constantly looks for ways to leverage the virtualization and transparency concepts within our server offerings. For example, PSI servers already enable customers to define virtual printers, terminals, and DASD devices.  This virtualization allows (for example) virtual DASD devices to be “backed” by SAN managed storage devices (usually SCSI disks).

      All current generation mainframe systems offer up (to programs) a virtual image of the physical CPU/engine, generally referred to as a logical CPU. This level of virtualization allows the system (hardware/firmware) implementation to dynamically “back” a logical engine with any available physical engine in the server configuration.  It is not too much of a stretch to envision a server where a logical engine (as perceived by executing programs) is physically backed through time sliced execution on two or more physical engines.

Ron, this was outstanding.  Many, many thanks.  You fielded some great questions and shed considerable light as to what PSI intends to offer the mainframe community.  I have to admit I am sold, thanks to what I heard from you. Ron keep up the good work and please come back and give us an update in a few months.  Thanks again, Ron.  All the best.  Give Gene my best wishes when you see him and show him over picture together from 1998.