Migrating Off the Mainframe

This topic comes up often. Too often. Those of us familiar with the mainframe get tired of repeating the facts for the resurging neophytes. (Methinks it must be a Microsoft or Oracle conspiracy ... they want to wear us down. Yeah, that's it.)

Over on LinkedIn there is a flame fest roaring through the "Mainframe Experts Network" group. One Frank Trovato innocently, if vaguely, asked ...

"Has anyone successfully migrated off mainframes?"

The responses include marketing and misinformation, mixed in with a hard-to-find smattering of real engineering. For my part, I argued that the S/390 line (or "System z") is more suited to certain workloads than a Pentium. This is no slam of other architectures. (Although one French Canadian continues to equate high dollar hardware with a historic hobbyist system.) Surely nVidia and Radeon are better for graphics than a regular INeL *86. Clearly ARM does better in your phone than a PPC chip. This is nothing more or less than "right tool / right job" pairing. Apply the same rationale to the central processor. Duh.

By coincidence, another noise in the web sphere is the demise of email at a major IT support house. If things were that simple, it might be no big deal. The "solution" seems to be "one size fits all" along with "all or nothing" replacement. People ... [sigh] ... THINK. This is not rocket science. This is not brain surgery. No time for that talk here.

Data Mover

A good way to look at the IBM mainframe is as a "data mover". (Careful ... if you use the phrase "big data", that only implies large addressability and Sir Jeff the Solar ... er, uh ... Sir Jeff the Scholar will tell you things you may already know about other 64-bit systems. That's not the point!) We're talking about input/output. The mainframe has employed channelized I/O since the original S/360. (Even prior, but the S/360 was probably the first to be quite so general ... at least in the IBM universe.) As an example, consider DEC. Once upon a time, they wanted the world to see their VAX line as a "mainframe". These were the days before any negative context. I loved the VAX but was truly offended by their abuse of the label "mainframe". DEC marketeers turned technical terminology into marketing mumbo-jumbo. The VAX hardly had channelized I/O. (Did have nice I/O vector spaces ... but that's a little different.) So the word mainframe in my dictionary means a computer with a robust isolation of input/output from other work. It can move big chunks of data. It can move big data in its sleep. Literally.

Trovato's question "Has anyone successfully migrated off mainframes?" in other industries could be stated as "Has anyone successfully migrated off grid power?" or "Has anyone successfully migrated off semi-trailers?" or "Has anyone successfully migrated off central A/C?". At my house, we still use grid power (sometimes it goes out) and we expect to always use central A/C. We don't directly use semi-trailers. I do have a 3/4 ton Chevy Suburban balanced against a Toyota Prius. More of that "right tool / right job" pairing.

There Can Be Only One

Well ... today, there is only one, sadly.

These days, you can only get "a mainframe" from IBM. Things were not always this way. There was a time when you could get plug-compatible (IBM compatible) computers from other hardware makers. The point is not so much compatibility with Big Blue but the availability of machines supporting that slick ISA for big data operations. (Ooopppsss... I said it again. Sorry Jeff.) The biggest problem with the mainframe is the single source for such hardware. Thankfully, we have Unix and Linux, so while the hardware has vendor lock-in, at least the environment does not.

IBM won the war ... or did they? As a customer, I don't like single source supply. It matters less with workload flexibility (the victory of Unix).

All About Performance

What then is the goal when considering a computing platform? Mainframes offer performance. Okay ... there is more to life than performance, but performance is a Big Deal. I work for a performance company. (Full disclosure: Velocity Software. Some have heard our leader's slogan, "If you can't measure it, I'm just not interested.", tm.) We do performance analysis and reporting for the z/VM system. It's all the more important because VM hosts other environments. (And should host more! but I digress.) Years ago, I didn't care about performance per se. But it has gotten to be a Big Deal for me as I see it becoming a Big Deal for a lot of Big Companies. (If I say "Big Deal" in caps often enough, can I trade mark it?)

Everyone should do this: Look at the facts. Figure out if the machine does what you want. Where it fails, make changes. Avoid ROT. Get real advice. Then measure again! And if you put all your eggs in one basket, be prepared for the bottom to drop out.

No Single Metric

Never let the discussion come down to just one thing. The differentiator may be just one feature. That which tips the scale might be just one attribute. But your consideration should always cover several points before you get to "the one".

Focus only on a single measurement and you'll go out of business. One measurement at a time? Yes. But only one ever? Bad idea. Even the highly respected "customer satisfaction" yard stick will not keep you going if you don't reign in costs. (This is why I work for Velocity: performance is one of those costs too easily ignored.)

Has Anyone?

Frank, it's an excellent question! As others have answered, "has anyone?". Yes. Yes they have. You bet! Have all migrations off the mainframe gone well? Hardly. Some have been catastrophic. Anyone asking today "should we?" deserves an "it depends" along with some sound advice.

A smarter move would be to evaluate individual computing workloads. Don't make it an all-or-nothing shift. Demand flexibility and interoperability from your vendors and support organizations. Move tasks to where they work best. (The wise executive would do the same with staff, rather than RIF them with a broad sword.) (Sorry ... my bad mood is showing.) You may find, as many have, that some workloads should move TO the mainframe. (Linux makes this especially appealing, but there's plenty of work to be shoved over to z/OS.)

There is no "one size fits all" and the bigger your IT needs grow the more you'll want to mix different architectures. It's common sense. You can run a whole organization on a mainframe. Does it make sense? Not in my book. You can run a whole organization on a PC. Does it make sense? Only if you believe the opinions of the inexperienced or the knee-jerks.

-- R; <><