Who Cares About Operating Systems?

A mainframe is more than just a computing device: it is a business computing platform; the difference is its operating systems. They are highly optimized to the mainframe hardware and context and embody over half a century of the requirements from the biggest users of business computing.

Obviously, there are many other computing platforms than the mainframe out there. Terms like "wintel" describe a generic PC with an Intel (or similar) processor running the Windows operating system. An Apple with some version of Mac OS is another example. A given hardware configuration may have multiple different operating system options (e.g. Windows and Linux, among others, for PCs), and a given operating system may have different versions that run on multiple different hardware platforms (e.g. Linux, which has versions for Intel-type PCs, but also for other hardware platforms including the mainframe).

The history of IT is rife with "holy wars" about operating systems, including what level of functionality is sufficient, whether they should be proprietary or open, and if they should be optimized to a specific hardware platform or generically available to many. Before Linux made it big and after the mainframe had become so taken-for-granted that it was already generally ignored and written off as extinct, there were big "holy wars" between supporters of Windows and of UNIX. A Dilbert comic from that era embodies this well: http://dilbert.com/strips/comic/1995-06-24/ depicts a "condescending UNIX computer user" telling Wally, likely a Windows user, "Here's a nickel, kid. Get yourself a better computer."

Of course, throughout that era, debates about such operating systems were able to proceed with more energy than urgency since the critically important work was already being handled by mainframes.

The four mainframe operating systems which have continued to be available for the past few decades are today known as: z/TPF, z/VSE, z/VM and z/OS.

Which leads to the question: what is it that these operating systems do?

Put simply, they provide a functioning context for all the applications that run on the mainframe to focus on what they do best, letting the operating systems handle everything from talking to the hardware to enabling many, many different tasks to run concurrently and safely with the best possible performance and availability.

Being written specifically for the IBM mainframe hardware, and having then evolved concurrent with it over time to respond to the demands of the biggest users on earth, this has resulted in a platform of unparalleled performance, capacity and reliability.

In addition to the four "z/" operating systems, there is also Linux available for the mainframe (though it generally runs as a "guest" under z/VM) and an interface to z/OS known as UNIX System Services (USS) or z/OS UNIX. Because each of these relies on one of the previously-mentioned operating systems to interact with the hardware of the mainframe, I'll save specific discussion of them for future blog entries, and focus this one on the aforementioned four.

Over the years, the names of these operating systems have changed. The original operating system announced for IBM's System/360 line of computers was to be known as OS/360, but the learning curve that came with developing such a complex operating system led to significant delays in delivery (as discussed in Fred Brooks' great book, "The Mythical Man-Month: Essays on Software Engineering."). So, as a stop-gap, IBM announced the scaled-down DOS/360 (for "Disk Operating System/360" - not to be confused with any of the other operating systems also known as DOS). OS/360 was eventually delivered, and it grew and changed and went through multiple names, becoming what we know today as z/OS. DOS/360 went through many twists and turns to become z/VSE.

I like to coin epigrams (just ask my kids, who have a compilation of what they call, "dad-isms"), and one of them is, "The temporary outlasts the permanent." This refers to the fact that we often adopt short-term measures without the detailed planning and perfectionism we would apply to something intended to last. Then, these short-term measures, free from the obligation of perfection, have grown, adapted and gained a life of their own. Meanwhile, the more carefully-planned results may see the world pass them by if we don't keep applying the same level of scrupulousness to their ongoing viability as we applied to their original development.

Interestingly enough, z/VSE and z/OS represent the two sides of viability inherent in this: the stop-gap that adapted and survived and the scrupulously-created high-quality result that continued to be maintained with great effort and attention.

Now, don't get me wrong: today's z/VSE is indeed a high-quality operating system, and has accrued many of the advantages originally developed for OS/360 and its successors over time. And, for that matter, it's always been "good enough" - so much so, that IBM's efforts to get its users to convert to OS/360's successors have never seen a complete conclusion.

In fact, that's one of the great stories of the mainframe: how IBM has tried to get the users of the "good enough" operating system to convert to the "top quality" operating system, and how those users have responded.

While my focus for this blog entry isn't to give an in-depth history of the mainframe context (I'm working on a book on that topic with my friend and colleague Dr. Stephen Guendert - stay tuned), it's worth following this thread a little way just to see a couple of noteworthy outcomes.

The first of these is z/VM. 1972 marked the beginning for a precursor to z/VM: VM/370. While this was intended to host multiple users in a time-sharing context, there are two very relevant aspects about it for this discussion: 1) it was the first Virtual Machine operating system, allowing multiple concurrent environments, including full mainframe operating system instances, to think they had the entire mainframe to themselves; and 2) it was employed as part of IBM's ongoing strategy to get the users of DOS/360's descendants to convert to OS/360's descendants by allowing them to run both operating systems concurrently on the same machine, thus allowing for a smooth and gradual cutover.

The other interesting thread is the emergence of a range of non-IBM operating systems that were generally enhanced alternatives to the successors of DOS/360. One of the most well-known of these was MVT/VSE from Software Pursuits, which my friend and colleague Tim Gregerson was closely involved with. He has shared many insights with me about this turbo-charged alternative to IBM's light mainframe OS, and I look forward to including some of them in the mainframe history book I mentioned above.

Lastly, let me give a tip-of-the-hat to z/TPF (or z/Transaction Processing Facility). Descended from the Airlines Control Program (ACP - developed in the mid-1960s), it is a highly-optimized environment for serving up intensive, real-time services such as airline reservations at the greatest of volumes. While it is the least commonly-used of the big four mainframe operating systems, for those who use it, nothing else comes close to the nature and scale of performance it offers.

Because all four of these operating systems run on the same hardware platform, they are able to benefit from significant cross-pollination. That means that RAS (Reliability, Availability, Serviceability/Scalability/Security) features of one can be repurposed or used to model similar aspects in the others.

When I say "the same hardware platform" it should not be construed to indicate that there's only one kind of IBM mainframe, of course. Rather, since the beginning, the System/360 and its descendants have provided an extremely wide range of capacities and performance characteristics. But they're all designed to be able to run the same software and operating systems, providing the functional equivalent of an extremely open platform.

However, operating systems are just one more layer of what makes the mainframe great, and the next layer is the one I know best. Next week: all the software between the operating systems and the applications, part one!