I don't expect this list will change anyone's mind -- but it will certainly make me feel better.
The graying of mainframe support
Well, okay, this one is true. I see a lot of gray heads when I look around my department. But in companies with aggressive job rotation programs, I also see a handful of college graduates eagerly taking up the challenge to become excellent systems programmers.
IBM recognized this problem years ago and has several outreach programs for getting students' hands dirty on big iron, such as its work with Share, whose zNextGen team promotes mainframe skill-building. They also are working with colleges to put more mainframes on campuses.
The mainframe is old technology
Virtualization (VM operating system, PR/SM) and goal-based performance management (WLM) are just two ideas originating on the mainframe that are now making their way onto the smaller platforms. Even so, Windows and UNIX have a long way to go before they match the bigger boxes' ease of maintenance and sophisticated diagnostic and debugging tools. Furthermore, to this day mainframes remain the industry's gold standard for security and system integrity.
It takes too many people to manage a mainframe
Most shops measure tech support staff sizes by drawing a circle around all the mainframe systems programmers and comparing that against the number of Unix system administrators. But that isn't the whole story.
If you look more closely, you'll see the mainframe staff supports more than just the operating system. The same department maintains transaction processors (CICS and IMS), databases (DB2 and DL/1) and programming languages along with a myriad of other products needed to keep the trains running.
A fair comparison should include the administrators who keep the smaller versions of transaction processors (WebSphere), databases (UDB, Oracle and SQL), languages and office tools, to name a few. Taking those technicians into account paints a more accurate picture of how much manpower it takes to keep the small boxes afloat.
Mainframe processors are too expensive
The development of mainframe CMOS processors truly drove the price versus performance graph through the floor. Now, some boxes have more processing power than one instance of the operating system can use, thus requiring customers split their systems into multiple logical partitions (LPAR) to soak the machines. Furthermore, IBM implemented "power on demand" through the use of central processors that are dormant until turned on when needed.
You still have to be careful. Chasing the latest and greatest processor family can be expensive and IBM has successfully shouldered the other hardware vendors out of the business. But there is a healthy and lucrative used processor market that can save a company a lot of money if they don't mind being a generation or two behind.
Lastly, the mainframe's workload management enables it to do two things. First, it can manage a diverse workload, from web back-end to ad-hoc batch jobs, while ensuring each one meets its performance goals. Second, the mainframe is comfortable running up to 90% utilization, something the other platforms can't match even with virtualization. In the Unix world, once utilization tops 50% the answer becomes BAGDS (Buy Another Gol-Durned Server).
Mainframes can't compete in an Internet-driven business world
IBM has spent the last ten years heavily investing in software to ensure it can. Today's CICS works quite well as a web site back-end or partner in service-oriented architecture (SOA) systems. IBM provides Application Assist Processors (zAAP) for executing Java. Lastly, the mainframe has the distinct advantage of already hosting the systems and information companies want to put on the web so the main challenge becomes how to interface to it. To the rescue are bucketfuls of software that can provide mainframe-based information to the web without changing the original applications.
As I said in the short introduction, I'm probably preaching to the choir. However, there are some myths people outside of the mainframe world believe because they never bother to ask. Then there are the myths we mainframers tell ourselves because we never think to question them. Sometimes you have to challenge received wisdom to do what is right for your company.
ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.
