Rewriting also doesn't usually make good business sense. Mike Dooley, software engineering manager at Harland Financial Solutions Inc. in Lake Mary, Fla., 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 Inc.'s] WebFocus,” says James Hinsey, administrative team leader at Parker Hannifin Corp. in Cleveland.
“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 Ltd. 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.”
The Risks of Rewriting
So for better or worse, the fate of Cobol is inextricably linked to that of the mainframe. Both are likely to be around for a long time to come. Migrating Cobol programs off the mainframe can yield faster performance and cost savings in some situations (Hirsch says the NYSE's options business went from spending $2.5 million annually for a hosted mainframe to $200,000 for an in-house distributed system that runs 10 to 20 times faster for real-time applications).
However, organizations may want to think carefully before rewriting those applications in another language. Cobol is easier to read and manage than C# or Java, says Crego, who calls Visual Basic, C and C# “write-only code.” And rewriting some Cobol programs can require four or five times as many program lines in Java or C#, says Vecchio. He describes such projects as “a maintenance nightmare waiting to happen.”
Rewriting Cobol carries other risks as well. The applications, which often dominate back-end processing, may embody years of accumulated business processes and business rules knowledge created by programmers who are no longer with the organization. “That’s where the risks come in. You're changing your code base as well as your knowledge base,” Hirsch says.
“Rewriting runs the risk of losing the business rules that are implied in the system that no one knows about,” says Crego. Some companies have started rewriting projects only to discover that they don't have the source code, or at least not the current version.
And you don't have to rewrite it. “There will always be systems that can run IBM 360 compiled code,” Crego says. Cobol can be modernized, and users can be insulated from the back end by links to Web-based applications. That's what Papé Group is doing. While 95% of its back-end systems remain in Cobol, front-end applications are moving to Web technologies, Swift says.