Storage Networking , Part 1 eBook: A storage network is any network that's designed to transport block-level storage protocols. But understanding the ins and outs of networked storage takes you deep into several of protocols. This guide covers SANs, Fibre Channels, Disk Arrays, Fabric, and IP Storage. » Storage Networking 2, Configuration and Planning eBook: Picking up where Part 1 left off, Part 2 of our look at storage networking examines configurations for SAN-attached servers and disk arrays, and also includes a look at the future of IP storage. » Storage Management Costs in the Enterprise: A Comparison of Mid-Range Array Solutions Whitepaper: Many factors contribute to the ownership cost for enterprise storage. These include (but are not limited to): physical capacity relative to physical space requirements, performance capacity for data transfer and system reaction time, software maintenance and updates, expandability and flexibility, and much more. » Storage Is Changing Fast  Be Ready or Be Left Behind PDF: The storage landscape is headed for dramatic change, thanks to new technologies like Fibre Channel over Ethernet (FCoE), pNFS, object-based storage and SAS that will affect everything from NAS and SANs to disk drives. Get the knowledge you need to make the most of your storage environment, now and in the future. » HP StorageWorks EVA4400 Demo: Dont settle for an expensive and complex array that lacks functionality. The HP StorageWorks EVA4400 delivers virtual storage with enterprise class functionality at an affordable price. »

Let's play a word association game, shall we? The first word is "mainframe."

Many Linux enthusiasts were born and bred in an era of PCs that are already fast and getting faster, cheap and getting cheaper. When you can buy a two-way Alpha box for five thousand dollars or a high-end Intel for even less, even administrators of large-scale servers are reluctant to spend seven figures on Big Iron from Big Blue. Besides, there's that whole legacy thing going on--you know, COBOL and RPG and punch cards. So when you saw that word "mainframe," there's a good chance that some of the words that came to mind were: expensive, cumbersome, proprietary, obsolete, DINOSAUR.

You would be wrong on the first four words, but right about that last one: dinosaur. You were probably thinking of a lumbering, walnut-brained lummox like Brontosaurus, though. Wrong dinosaur. Instead, try Tyrannosaurus Rex. Mainframes today are like the dinosaurs in Jurassic Park: they're back, and they're pissed!

Wait a minute--T. Rex is not quite right, either. Let's say, a herd of forty thousand raptors. Later in this article, you will understand why.

Taking A New Look at Big Iron
I first started working with IBM's mainframes in college in the early 1980s. We had two systems then: MVS for running batch jobs from punch cards and VM for running interactive programs on a terminal. I hated punch cards (everybody did) but I was impressed by what you could do with MVS. The Job Control Language (JCL), though extremely cryptic, was capable of magical things if one only troubled to learn its secrets. I did so, and I think some of the same things I like about Linux are things that I liked about MVS. I don't care how user-friendly something is, but I demand tools that are versatile and efficient. MVS is still with us today, although now it's called OS/390 by IBM. Punch cards have been retired in favor of sequential files, but the basics of JCL are still there. OS/390 is at the core of most of the world's major corporations, and it has evolved more than I would ever have imagined.

I only got to play with VM, the "other" mainframe system, my last two years of college. VM stands for "Virtual Machine," as you might imagine. When I used it in college, I noticed that each user had the illusion of his or her own machine. You had your own virtual hardware of a mini-mainframe: card reader, card punch, console, printer, and disk drives. It was cute, I thought, kind of a nifty little way to make the mainframe approachable to new users.

It wasn't until a few years ago, working for a big company that has both VM and OS/390 systems, that I began to understand that VM is much more than a user-interface model. You see, when IBM says "Virtual Machine" they really mean it--all the way down to the bare metal! It turns out that IBM's System/390, or S/390, hardware (not to be confused with the OS/390 operating system) has specialized circuits (called PR/SM and SIE in IBM parlance) in the CPU to allow it to virtualize itself. If you're an assembly-language programmer in the Intel world, you may be familiar with the "Virtual 86" mode that is present in the 386 and later processors. V86 mode lets an Intel processor emulate the venerable 8086/88 chips that were used in the days of DOS and Windows 2.x. The S/390 doesn't just emulate a subset of itself, though, but rather the entire instruction set of the latest CPU.

That word emulate really doesn't apply, either. The S/390 actually virtualizes itself in hardware, meaning that applications run at full native speed except for a very, very few privileged instructions that are actually emulated by the operating system. Everything is virtualized, right down to the hardware I/O addresses and memory map. It's like having NT's HAL (Hardware Abstraction Layer) actually implemented in hardware. The VM operating system takes full advantage of this by literally giving each user session its own virtual machine, which has practically the same capabilities as the hardware itself. So when a user logs in and thinks they have their own computer, they practically do. The magic of virtualization is wrought by a program called CP, or Control Program, which underlies the operating system to manage the virtual hardware.

The virtual machines in VM are so good, in fact, that you can literally boot and run VM as a "guest" operating system underneath itself. Then you can boot another VM inside that one, and so on. They don't even have to be the same version or even the same operating system. I know a mainframe wizard who has booted a new (test) version of VM underneath a user session on his production VM system, then loaded a complete OS/390 into that virtual machine. When I asked him why he did it, he said, "Because I can!" With VM, though, this isn't just a stunt, but an everyday occurrence, used for testing new operating system versions and patches without stopping production even for a minute.

Next: New Life for Old Machines »