Shows & Panels
- AFCEA Answers
- Ask the CIO
- The Big Data Dilemma
- Carrying On with Continuity of Operations
- Connected Government
- Constituent Servicing
- Continuous Monitoring: Tools and Techniques for Trustworthy Government IT
- The Cyber Imperative
- Cyber Solutions for 2013 and Beyond
- The Data Privacy Imperative: Safeguarding Sensitive Data
- Expert Voices
- Federal Executive Forum
- Federal IT Challenge
- Federal Tech Talk
- Mission-critical Apps in the Cloud
- The Modern Federal Threat Landscape
- The Path from Legacy Systems
- The Real Deal on Digital Government
- The Reality of Continuous Monitoring... Is Your Agency Secure?
- Veterans in Private Sector: Making the Transition
Shows & Panels
Monday - Friday, 6-9 a.m.
Hosts Tom Temin and Emily Kopp bring you the latest news affecting the federal community each weekday morning, featuring interviews with top government executives and contractors. Listen live from 6 to 9 a.m. or download archived interviews on our daily show blogs.
How, and why, to modernize the legacy of COBOL
Tuesday - 6/1/2010, 9:31am EDT
Federal News Radio
Many analysts are saying that federal agencies should work to move away from COBOL.
COmmon Business-Oriented Language (COBOL) was invented in 1959 by Naval officer Grace Hopper and is still used widely throughout the federal government.
The language is touted as secure and easy to learn, but it's also old, and can't quite get the job done.
Tom Bragg is the president of ResQSoft, Inc. and said he thinks there are instances where COBOL can be encapsulated and run forever, but that might not always be the best course of action.
"The problem is that the ability of people to maintain that software and to modify it to meet new requirements, like new regulations, decreases greatly over time. A lot of the people who are maintaining that software today are in their 50's and are eligible for retirement. That's a big problem."
COBOL is probably the most widely-run language in the world today, he added. Despite this, the number of people who know it continues to dwindle every year, and no one learns COBOL in school anymore.
"Younger software engineers, as they call themselves, don't want to be mainframe programmers. When you couple those factors with the fact that nobody is making new tools for COBOL, the ability of a software programmer to make a change required by a new law or a new regulation or a new desire to provide services to constituents is very limited compared to the newer languages. The other factor is that newer languages run on much less expensive hardware, so some people spend tens or even hundreds of millions of dollars running mainframe computers when they don't have to."
Moving away from COBOL doesn't have to be a challenge, either. Bragg explained that often two (or more) different platforms are working with each other, so the older programs that need COBOL are running on the mainframe -- separate from where the software is.
"So, what you do basically is put in the new capability and test it against the old to see whether you get the same results or not. You have some choices. You can rewrite the software by hand. You can try to put a package in that does the same thing, and you can use automated tools to translate the code or redevelop it so that the code looks like human programmers wrote it."
Bragg explains that his company performs the latter task. They rework information from old programs, put that into a database or repository, and then create brand new programs that appear as though they were created by people.
The cost to do this depends on how the contract is written and what's being translated.
"Basically, modern translators will come in at about 75 cents per line of code. Automated redevelopment will come in typically at about $1.50 per line of code. Rewriting it by hand can be $7 per line. The question, basically, is how much code do you have and, in terms of time, we've completed two million line projects in less than a year. Some of the other approaches take a little longer, but, basically, the problem is that you have to start. If you never start, then when you're 4 COBOL programmers come into the office and say -- 'Boss, the economy's gotten better and we're quitting', then you're stuck."