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 to discuss email "to be or not to be" 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; <><

by sirsanta December 9, 2011
Permalink

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d834521c8469e2015394430347970b

Listed below are links to weblogs that reference Migrating Off the Mainframe:

Comments

We really are ending up with a "Boeing and Airbus" market for server hardware, although in this case it's IBM and Intel. IBM offers zEnterprise and POWER CPUs, while Intel offers X86 CPUs. We may or may not see ARM CPUs enter the server market -- to be determined. (HP bet on Itanium, outsourcing its R&D to Intel, and lost. Oracle/Sun is trying to hang onto whatever SPARC business is left, but that isn't going to work.)

That's it. If that's "vendor lock-in," then that's what we have. But it's Intel vendor lock-in, too. It's a byproduct of the fact that, just as with commercial airliners, it takes an enormous amount of sustained R&D to compete credibly in the server hardware marketplace. And there are only two companies left which can sustain that R&D.

Does hardware vendor "lock-in" matter? It wouldn't seem so. Hardware seems to be an ever-shrinking component of total IT spending. Frankly I don't know why people worry about it as much as they do. In other words, just as with the commercial airliner market, the server hardware market is extremely competitive.

Posted by: Timothy | Dec 13, 2011 5:08:37 AM

The answer is Yes and the key to success is having a good knowledge of the both sides (source/target) and to succesfully manage to get the right skills and to manage cultural change. When you culturally federate both sides and identify a good sometime moving target, it becomes almost easy and straightforward. It's a kind of human alchemy in some way : planning and communications are important issues.
Regards

Posted by: aproult | Jan 10, 2012 9:27:56 AM

Actually, IBM is one of several mainframe manufacturers. Fujitsu and Hitachi sell /390-based systems, while Unisys, Bull, and NEC maintain their own architectures.

Posted by: Kira | Jan 19, 2012 3:50:07 AM

Sure does the Mainframes have great I/O capacity, because they can have 296.000 I/O channels, with several I/O cpus. But cpu wise, the Mainframes are not that fast.

There is a reason IBM never publishes SPEC_INT or other cpu benchmarks. In fact, a high end x86 cpu is much faster than the "worlds fastest" cpu z196 at 5.26GHz.

A guy ported Linux to Mainframes, and he compared to Linux on x86. He came up with the rule of thumb, that 1 MIPS equals 4 MHz x86:
http://www.mail-archive.com/linux-390@vm.marist.edu/msg18587.html

Also, you can emulate a Mainframe via Hercules software, and achieve 3.200 MIPS on a x86 server. Software emulation which is 5-10x slower:
http://en.wikipedia.org/wiki/Hercules_emulator#Performance

Remember that I now speak of CPU performance. The whole mainframe is fast, because it has lots of co processors. But if only look at the z196 Mainframe cpu, it is slow. Again, you will never see any z196 benchmarks from IBM. IBM wants to hide the fact the z196 is slower than x86.

Posted by: Kebabbert | Feb 2, 2012 4:19:18 AM

The comments to this entry are closed.



The postings on this site are our own and don’t necessarily represent the positions, strategies or opinions of our employers.
© Copyright 2005 the respective authors of the Mainframe Weblog.