The mainframe computer appears to have more lives than the proverbial cat. Pronounced dead time and again since
the late 1980s when Microsoft said the future of business computing was the PC running Windows, big iron is hanging in 20 years later despite the advent of blade servers, grid computing and the dual-core microprocessor.
In the service-oriented architecture (SOA) world, the supposedly moribund mainframe keeps popping up like a Jack-in-the-Box on steroids.
The reason the mainframe will not die is a simple matter of arithmetic, explains Dave Locke, director for IBM Rational worldwide marketing strategy.
"There's tons of good working programming on mainframes," he said. "Almost all of it is in COBOL with some in PL/1 and other languages. There are some 200 billion lines of COBOL. It's been said that if we replaced all that COBOL it would cost $20 trillion."
Even if you work at a Wall Street investment firm, you might concede that $20 trillion is a lot of money, but Locke offers other reasons why even in the era of SOA, the mainframe should not be relegated to the dustbin of business computing history.
"Mainframes are great at high volume processing, with huge storage, lots of MIPS and high security," he said.
For enterprise SOA what's not to like?
"We see in the marketplace that there is definitely a resurgence of mainframes," Locke said.
His assertion is backed up by a survey of SHARE members, the independent IBM mainframe users group, which was conducted this past summer. Joe McKendrick, the analyst, who wrote up the survey results in a report, titled "The New Mainframe: Data Integration and Service-Oriented Architecture, Big Iron Style," concluded that SOA was actually causing a mainframe renaissance.
Noting that 70 percent of mission critical applications and data still reside on mainframes, McKendrick wrote that enterprises are now looking to integrate the big iron into their SOA applications.
However, as Locke points out most new SOA coding is being done in Java, while almost all the applications on mainframes were written in COBOL and are to this day being maintained and updated by COBOL programmers.
The ideal solution for SOA implementations might be to retrain the COBOL programmers to work in Java, but that is easier said than done, Locke said.
"We've found you can't really retrain a COBOL person to be a Java developer," he said. "They think about the problems differently. How you architect and write the code is so different."
To bridge the gap, IBM Rational is releasing a series of products this month and last designed to identify COBOL programs that could become components in an SOA implementation.
Rational Business Developer Extension v7.0, released in November, relies on Enterprise Generation Language (EGL), "a strategic business development language used to create applications that can run on practically all platforms, from rich Web applications to CICS transactions," according to the IBM announcement.
EGL is a high level language, Locke said, that COBOL programmers can use to move into the SOA world without learning Java.
"This language is a high level language where it is easier to write code than COBOL," he said. "EGL has higher level constructs that makes it do more work per line of code. It also has specific support for SOA and componentization. That's important because it really reduces that amount of skill and expertise a COBOL developer needs to have to componentize and leverage SOA, because the language directly supports SOA."
Since before you can turn legacy COBOL code into SOA components, you have to find the programs that will work as components, this month IBM Rational is releasing IBM Rational Transformation Workbench v3.1, which looks at the old mainframe programs and identifies the ones that will work as components.
The idea is to find the application meatballs in the COBOL spaghetti.
"We can't just let that known good stuff go to waste because we've made a huge investment in it and it's operating our business today," Locke said.