That's the situation faced by Jim Gwinn, chief information officer for the USDA's Farm Service Agency. The USDA's System/36 and AS/400 systems run Cobol programs that process $25 billion in farm loans and programs. "We have millions of lines of Cobol and there's a long history of it being rewritten," he says. "It has become increasingly difficult to change the code because of the complexity and the attrition of the knowledge base that wrote it." That's a big problem because laws that govern farm programs change every year, driving a need to update the code to reflect those changes.
Gwinn hired consultants from IBM, who concluded that rewriting the programs in a different language or rehosting them on a distributed computing platform would be complicated and costly. But the System/36 hardware had to go, so Gwinn decided to bite the bullet: FSA will move off of its end-of-life mainframe systems by rewriting some of the code in Java and replacing the rest with packaged software from SAP.
But Gwinn says he'll miss Cobol. "It has been very stable and consistent, with little breakage due to code changes, which you see with Java-based changes," he says. "And in a distributed environment you have to balance your workloads a little more carefully."
Going for a rewrite
The anticipated exit of institutional knowledge and shortage of Cobol programmers were also primary drivers behind NYSE Euronext's decision to reengineer 1 million lines of Cobol on a mainframe that ran the stock exchange's post-trade systems. While Cobol was dependable, it wasn't viewed as maintainable in the long run.
Steven Hirsch, chief architect and chief data officer, cites the need to make changes very rapidly as another key reason the NYSE abandoned Cobol. "Ultimately, the code was not easily changeable in terms of what the business needed to move forward. We were pushing the envelope of what it took to scale the Cobol environment," he says.
So NYSE rewrote Cobol programs that run its post-trade systems for Ab Initio, a parallel-processing platform that runs under Linux on high-end Hewlett-Packard DL580 servers. The new environment allows for more rapid development, and the rewrite also eliminated a substantial amount of unnecessary and redundant code that had crept into the original Cobol programs over the years.
If the business' Cobol code doesn't need to change much, and many batch and transaction processing programs don't, it can be maintained on or off of the mainframe indefinitely. But that philosophy wouldn't work for NYSE. "We are a rapidly changing business and we needed to move faster than our legacy code," Hirsch says.
As for trading, that's all proprietary NYSE Euronext software. "There's no Big Iron or Cobol," Hirsch explains. "There's been no use of mainframes in the trading environment for many years."
Rehosting: Lift and shift
When it comes to hiring new Cobol programmers, Jonathan J. Miller, director of information systems and services for Saginaw County, Michigan, is struggling. "We've lost our systems programming staff," he says. And like many government IT organizations that have suffered from budget cuts, he doesn't have much to offer those in-demand Cobol programmers.
Generous government benefits used to attract candidates even when salaries were lower than in private business. Now, he says, "Our pay hasn't increased in eight years and benefits are diminished." To fill in the gap, the county has been forced to contract with retired employees and outsource Cobol maintenance and support to a third party -- something that just 18 percent of Computerworld readers say they are doing today.