Until a few months ago, the clearing and billing system for NYSE Group Inc.’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 of 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 recentComputerworld survey of IT managers, 218 — or 62% — said they use Cobol. Of those 218 respondents, 36% said they plan to gradually migrate off of it and 25% 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 Corp’s .Net Framework and integrates with the Visual Studio suite of programming tools.
An Image Problem
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 Papé 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 Inc. in Stamford, Conn.
What programming languages do you use in your organization? Choose all that apply.
Source: Computerworld survey of 352 readers
If you don’t use Cobol, why not?
| Cobol is an outdated language. – 55% |
| Cobol is an inferior language compared to the ones we use. – 34% |
| Our enterprise is too new to have Cobol applications. – 27% |
| Lack of Cobol skills in-house or in the labor market. – 24% |
| Our enterprise is too small to have Cobol applications. – 17% |
If your organization uses Cobol, how much internally developed business application software is written in Cobol?
If your organization uses Cobol, are you using it to develop new business applications?
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.
Business Logic
Dooley sees recompiling for Cobol.Net as a way to facilitate integration of Harland’s back-office Cobol applications with front-end programs that are written in .Net languages. “If we get it into Cobol.Net, then the Visual Basic .Net application can call the same routines … without having to jump through hoops,” he says. New interactive online applications, such as a Harland’s delinquent-loan system, are written entirely in native .Net languages. With the rest of the Cobol in the .Net fold, he says, “we can make better decisions of where we can move business logic.”
Attorneys’ Title Insurance Fund Inc. in Orlando is rewriting nearly 2,000 back-end mainframe Cobol programs in C#, a process that senior analyst Kirk Gagnon expects to take three to five years. To do that, the firm is outsourcing maintenance of the system in order to free up the mainframe support staff to train on .Net tools and products including Visual Studio, BizTalk and MSMQ-MQSeries Bridge software. “We’re streamlining everything into one common set of software,” he says.
But even with skilled mainframe programmers at the helm, the project represents a big leap. “We haven’t done anything this large before,” Gagnon says.
Migrating off the mainframe and rewriting the code at the same time can be “a recipe for disaster,” says Vecchio. He notes that the desire to move away from Cobol is most often driven by one of three factors: the desire to reduce total cost of ownership, a need to address the perceived Cobol skills deficit or the mistaken belief that the only way to attain business agility is to move off Cobol entirely.
Hirsch is taking it one step at a time, first migrating off the mainframe and porting the Cobol programs with as few changes as possible. From there, programs should be reassessed, not just rewritten, Vecchio says. “You need to rethink, How do I perform that function? not just, How do I do it in the same way on a new platform?” he says.
“Why would anyone ever write an application from scratch when there are so many ways to deliver pieces and parts of that?” Vecchio asks. Some programs may not be needed, while others can be eliminated by moving to packaged applications. Business process management tools and rules engines can be used to replace still others.
And perhaps, just maybe, some programs, such as those used in batch processing, should be recompiled and modernized in Cobol. “There are environments where thinking procedurally is better,” Vecchio says.
Just because your front end is object-oriented doesn’t mean the back end needs to be as well, says Crego. “You could have a different language on the front end being very interactive, and on the back end, you could have a robust business language, and there’s no reason why Cobol wouldn’t fit into that space” he says.
Is Cobol dead? Not by a long shot, says Vecchio, but it’s likely to continue its long, slow decline. Once center stage in state-of-the-art computing, the language is no longer the focus of innovation in business. “New packages and programs aren’t being developed . Skills are declining. All of these things are working against a resurgence,” he says.
Organizations should plan to move off Cobol at some point, but that possibility shouldn’t be the driving force behind any decisions.
“Focus on what is best for your organization, not what is the hot technology right now. That doesn’t mean that the hot technology isn’t where you want to get eventually” Swift says. But business process needs, not the choice of programming language, should dictate when to make such a move.
Related News and Opinion:
• Weekly I/O: Podcast interview with Robert Mitchell about the Cobol article
• Robert L. Mitchell: Cobol not so procedural after all
• Sound Off: Cobol versus Java and C#
• Robert L. Mitchell: How they learned to stop worrying and love Cobol
• Martin MC Brown: 10 programming languages to learn
• Shark Tank: Think Global, Act Loco