Until a few months ago, the clearing and billing system for NYSE Group's stock options exchange consisted of about 800 discrete Cobol programs running on an IBM mainframe. Today, the entire application set has migrated onto a pair of clustered, quadprocessor Windows servers. The recompiled programs remain in Cobol today, but they won't stay there for long.
"It's not our long-term goal to remain running the Cobol applications. That was a tactical move, designed to slide the existing applications off the mainframe with as little disruption as possible," says Steven Hirsch, vice president of technology support at the stock exchange. Within the next few years, he expects everything to be rewritten to conform to the NYSE's standard development platforms: Java and C. What's more, other Cobol-based systems that power the New York Stock Exchange are "deeply engaged in a similar replatforming effort," Hirsch says.
NYSE isn't the only organization that would like to abandon Cobol. Of 352 respondents to a recent Computerworld US survey of IT managers, 218 -- or 62 percent -- said they use Cobol. Of those 218 respondents, 36 percent said they plan to gradually migrate off of it and 25 percent said that they would do so if it weren't for the expense of rewriting all of that code.
So what's wrong with Cobol? The technology, which has been around since 1960, is rock-solid. It excels at batch processing and is practically self-documenting, and tools for it have not only been modernized but also support distributed systems. Vendor Micro Focus International Ltd. even offers Cobol.Net, a part of its Net Express offering that fits neatly into Microsoft's .Net Framework and integrates with the Visual Studio suite of programming tools.
But Cobol is also a procedural language in an object-oriented world. While it's well suited to batch operations, the language isn't as good a fit for developing interactive applications or Web-based front ends. And it has a major image problem. Outside of the mainframe data center, Cobol is viewed today by many Java, Visual Basic and C# programmers as an obsolete and inferior language, a vestige from the dark ages of big iron.
Most new Cobol programs are written only to extend or support existing applications on the mainframe. For example, Shaun Swift, director of information systems at capital goods retailer Pape Group Inc. in Eugene, Ore., says his company writes new Cobol applications for his back-end systems to accommodate acquisitions.
When Cobol applications are migrated over to Windows, Unix or distributed systems, they remain in Cobol because rewriting them is expensive and risky, not because Cobol might be the best choice for the application. "Nobody wants Cobol, but realistically they can't get rid of it," says Dale Vecchio, an analyst at Gartner.
Rewriting also doesn't usually make good business sense. Mike Dooley, software engineering manager at Harland Financial Solutions, has no plans to rewrite his 1,000 Cobol programs. "What are you getting for the expense?" he says, adding that such a project would take years to complete. "You have to have a valid business reason to do that."
Swift also plans to stay put. "I don't see any advantage. How does that help with customer satisfaction?" he says.
For greenfield application development, the use of Cobol is practically nonexistent. "We're not doing anything else except supporting what we have in Cobol. Any new development is done in SharePoint or [Information Builders's] WebFocus," says James Hinsey, administrative team leader at Parker Hannifin.
"Any new development we do is purely in Java," says Mike Zucker, director of applications development at the University of Miami. Cobol is "out of vogue," he says, but adds that he'd still use Cobol if components for a new application required batch processing. Both Parker Hannifin and UM make extensive use of Cobol on the mainframe for back-end processing and have no immediate plans to change that.
"I went out and tried to find anyone doing bare-bones, new development in Cobol, and I'm hard-pressed to find even one," says Mark Crego, chief architect at Accenture. That's a shame, he says. Crego calls Cobol a "superb language" for large-scale processing of records. But today, outside of the mainframe world, the language co-invented by the legendary Rear Adm. Grace Murray Hopper simply gets no respect.
Cobol, says Vecchio, "has been tainted with the brush of mainframes."