In-Depth
An Rx for Mainframe Viability
If the mainframe is to remain a viable platform for the next forty years, IBM Corp. may need to do more to address some of its most glaring pain points
If the mainframe is to remain a viable platform, IBM Corp. needs to do more to address some of its most glaring pain points, including the prohibitive cost of mainframe hardware and software, the (often substantial) impediments to legacy application modernization, and the problems associated with recruiting and educating a new generation of mainframe pros.
That’s just the beginning. While mainframe users generally give Big Blue so-so marks on all three accounts, some think IBM is almost purposefully ignoring the most significant issues.
Take Ben Teifeld, a principal with consultancy and integrator Teifeld & Associates, who says that IBM needs to get serious about reducing the mainframe’s all-but-prohibitive cost of entry.
“The entry-level cost risk is beyond imagination. IBM has no entry-level mainframe offering save for one emulator implementation offered by one company on a limited number of approved configurations,” he writes. “The entry-level cost of this combination, without operating system or development software, is at least $20,000.”
As Teifeld notes, no sane CIO is going to consider such an outlay a reasonable risk—and that’s even before he or she gets a taste of the sky-high pricing of most mainframe software.
Similarly, Teifeld says, IBM needs to do a lot more to recast the mainframe as a viable platform for enterprise software development. Software development for Linux or Windows platforms is a cinch, Teifeld says, but in the mainframe space, it’s complicated on several different levels. For example, he argues, Big Blue’s Partner in Development program for zSeries is handicapped in crucial respects. “IBM only makes available a full development system environment for z/OS, the most expensive platform option next to [Transaction Processing Facility] TPF. To get the privilege of using the Application Development CD, you must first get one of the approved platforms for it, and then you must commit to developing three applications a year in order keep using it.”
To its credit, IBM has introduced several programs designed to help make the mainframe more accessible to non-traditional consumers. Big Blue’s z/OS Shared Remote Development Program, for example, makes Big Iron capacity available over the Internet to developers who want to work in either z/OS or z/VM. In this case, the prohibitive upfront costs of mainframe hardware and software are defrayed—or, more correctly, supplanted by a monthly subscription fee.
At the same time, access to CICS and DB2 development is only available under z/OS, while support for specialty platforms like TPF is non-existent. And the cost of the program would break the banks of all but the most enterprising of Windows or Linux code jockeys—not to mention their cash-strapped IT departments. Basic z/OS access is $12,000 annually, CICS and DB2 access is $18,000 annually; and Select Access (which includes CICS and DB2) is $24,000 annually. (z/VM access is a bit more affordable—at $500 per month, or $6,000 annually.) Above all else, IBM’s Shared Remote Development Program is a shared-only environment, in which multiple developers share one system image.
That’s just the tip of the iceberg, says Teifeld. “I will point out that there is no application development CD program of any kind for two of IBM's most interesting and practical environments, z/VM and TPF,” he writes. TPF, in particular, gets the short end of the stick; he says IBM charges much more for that environment than it does for z/OS. Nor is TPF approved and/or certified for use on emulated mainframe systems.
Back to the Books
Of course, there is a sense in which IBM is demonstrably committed to making mainframe hardware and software available to non-traditional programmers and operators, often for little or no cost. Big Blue’s Academic Initiative for zSeries helps to familiarize students with mainframe concepts and methods. It gives students and instructors hands-on access to zSeries mainframes, a Big Iron-oriented curriculum, assistance from experts, and dedicated training for students and faculty. The goal, IBM officials say, is to help students develop practical mainframe skills that enable them to step into good-paying jobs once they graduate, helping to offset the exodus of retiring mainframe experts.
IBM has ambitious goals for this program. It hopes to train as many as 20,000 mainframe-capable professionals by 2010.
That’s just the beginning, of course. There’s only so much that can be taught in a classroom or experienced in a computer science lab; much of the work of educating the next generation of mainframe professionals will take place on the job, as knowledge is transferred from older mainframe pros to those whose hairlines are still (hopefully) intact.
IBM officials tend to shift gears when pressed to disclose just how many would-be mainframe pros are today cutting their teeth in its collegiate farm system, however. Instead, says Mike Bliss, director of IBM System z9 and zSeries with IBM, the question needs to be framed in a different way—namely, why not the mainframe?
“The thing that could get a student excited, when you were in college, what were the things that were important to you? For me, the most important thing was being challenged intellectually, and the second was, is what I’m learning going to have job opportunities for me? Students are starting to realize that the mainframe environment is hugely important, and that it’s going to be just as important 20 years from now,” he observes.
As more and more students take this message to heart, Bliss argues, IBM’s Academic Initiative for zSeries will bear fruit.
Josh Smith, a mainframe system programmer with The Timken Co., a Canton, Ohio-based manufacturing giant, is one of Big Blue’s first collegiate success stories. His experience amounts to a proof-of-concept of Bliss’ optimistic take on the Academic Initiative for zSeries.
Smith’s first exposure to mainframe coding was in college, when he had a chance to program Assembler on mainframe hardware that IBM donated to his school as part of the Academic Initiative for zSeries. More to the point, Smith—like many of his peers—came to Big Iron knowing little more than that as a platform it was on the way out.
“My senior year of college, I took an Assembler class. I had spoken to the professor before … and asked him what platform he was using. I remember he said he was considering using the IBM mainframe, and I said something to him to the effect [that] isn’t that really going out? Are people even using mainframes anymore? And he said people are not only using mainframes but actually buying more of them, too,” Smith recalls.
It also helped that Smith, unlike many computer science grads, found COBOL to be a refreshing change from object-oriented development in C or C++. “It’s a little easier to read than some of the other languages, especially compared to C++. It reads almost like English,” he comments, noting that COBOL is typically more extensively documented than its 3GL brethren.
All in all, Smith says, he likes programming for mainframe systems, which—in many cases—are easier to develop for than distributed platforms. “Depending on what you want to do, some things are just a lot easier on the mainframe in general or in COBOL in particular, as compared to, say, Visual C,” he concludes. “We use a lot of flat files here at Timken. We have databases, but we also have a lot of flat files. Database use is about the same in difficulty in both mainframes and distributed sysetms, but flat files are far easier in the mainframe world.”
Reality Check
Some mainframe problems have no easy answers. For example, legacy applications that were written before the advent of client/server—and which are premised on very different assumptions about program logic and presentation logic—can’t easily be refitted for the future. As a result, organizations must grapple with tough choices (including re-writing these applications or abandoning them altogether) as they pursue service-enablement strategies.
Still other mainframe problems seem to be of IBM’s own making, exasperated technologists say. The high cost of z/OS capacity relative to Linux or J2EE workloads running on the mainframe has compromised the viability of these applications—and of the mainframe itself—in some environments.
And Big Blue’s support of specialty operating environments, such as TPF or VSE, has also been called into question. “IBM has eliminated the ESL licensing tier, which allowed a one-time charge for processors with 8 MIPS or less,” Tiefeld points out. “This has in effect killed existing VSE/VM business which relied on that structure.”
And while there’s considerable concern about the degree to which offshore outsourcing will impact mainframe livelihoods, Tiefeld says that’s a secondary point. Instead, he argues, Big Iron enthusiasts need to more aggressively interrogate Big Blue itself.
“I think that before you talk about business and their willingness to allow their intellectual capital to be stolen through outsourcing to third world backwaters by dumping their mainframe assets over there, you need to take a critical look at IBM itself and their own practices,” he concludes. “The mainframe deserves more attention and business, but it isn't going to get it if IBM keeps doing business” in a way that’s unresponsive to the needs of users.
Related Articles:
Careers: Big Iron's Catch-22
http://www.esj.com/Enterprise/article.aspx?EditorialsID=1520
SOA: The Rewrite-vs.-Replace Dilemma
http://www.esj.com/enterprise/article.aspx?EditorialsID=1527