Mainframes Live: But the Clock Ticks on Legacy Apps

A couple of months ago I was invited to a 40th birthday celebration for the IBM System/360 mainframe at the Computer History Museum in Silicon Valley. I can’t say I was thrilled at the prospect, but I came away inspired. Launch team members described the incredible risk and resources ($5 billion in early 1960s’ dollars) that went into the project. And of course, they were puffed with pride that the 360 has lasted so long.

What’s behind the staying power? Part of the answer probably lies in the 360’s OS?which Fred Brooks, Jr., who led the development of the 360, calls “the first industrial-strength, 24/7 operating system.” The ability to assume a computer would be up rather than down cemented “IBM mainframe” and “reliability” in people’s heads.

But for mainframes generically, that reputation derived from ironclad procedure as much as anything else. My father-in-law, Clark Jones, programmed IBM 360s and RCA Spectra 70s in the 1960s and 1970s. He likes to talk about mainframe culture and rigorous “change control,” contrasting it with the PC server culture of “whiz kids” who never learned the basic operational rules necessary to avoid costly mistakes.

My father-in-law retired a few years ago, and therein lies the mainframe’s biggest problem. Many businesses seem to be happy to run their big iron indefinitely, but people who know Cobol or PL/1 are getting harder to find.

According to Gartner, the number of Cobol programmers will decline from just shy of 2 million this year to 1.5 million in 2007. You may not need to power down the mainframe next week, but it’s certainly time to think ahead about moving off it.

There are two smart approaches to the transition. You can retire mainframe applications piece by piece and replace them with, say, Java apps running on an app server. This results in what IBM calls “mixed workload” apps that span the mainframe and other platforms. But it also demands Cobol expertise that may not be available.

The other approach involves moving mainframe apps to another platform in one piece, more or less. Micro Focus in April announced a partnership with Microsoft to provide software that enables CICS applications written in Cobol to run on Windows. After they move the code, developers can use Visual Studio to modify the Cobol, or they can work around the legacy app, using Web services and native .Net languages like Visual Basic or C#.

“What people have figured out is they’re paying obscene quantities of money,” says Charles Fitzgerald, Microsoft’s general manager of platform strategies, who observes that mainframe MIPS costs three orders of magnitude more than Intel MIPS. “The thing that’s really preserved the mainframe over the past couple of years has not been performance; it hasn’t been throughput, because those things turn out to be terrible,” Fitzgerald asserts. “It’s been the set of operational practices that have been codified around it.” Naturally, Fitzgerald is convinced that this rigor is making its way onto server-based platforms.

Maybe so. Microsoft has certainly been addressing Windows’ reliability and security in a very public way. And BEA Systems and IBM routinely promote the bulletproof character of their Java platforms. As for hardware, an Intel-based Dell server tricked out with all the redundancy extras probably delivers uptime comparable to that of an IBM zSeries. But you can’t get away from the fact that IT is a victim of its own success: Far more people touch enterprise apps and hardware than they did four decades ago, which can’t help but increase risk. And ultimately, much of the modern hype about always-on utility or on-demand computing amounts to a yearning for those predictable days when guys in white coats roamed air-conditioned rooms.