Primer: Object-Oriented COBOL

What is it? A demonstration that it's possible to teach an old dog new tricks, long past the time anyone thought the dog had any trick left in it.

COBOL (Common Business Oriented Language) is one of the oldest and most widespread programming languages used to create or maintain business applications. Though nearly 5 billion lines of new COBOL code are written every year, COBOL itself is generally considered, if not dead, then hopelessly obsolete. That is unfair in that modern COBOL development tools and compilers support all the technology other languages support. COBOL is not only well-known, it's also available royalty-free. The language has been repeatedly modernized, most recently in a version certified as a public standard by the International Organization for Standardization (ISO) and the American National Standards Institute (ANSI) in 2002. That version includes support for most modern programming technology, including the ability to run multiple threads of a single application; support for Linux, Windows, Unix and other operating systems; and the ability to interconnect with software written using Internet standards HTML, XML, Sun Microsystems Inc.'s Java or Microsoft Corp.'s .Net.

Object-oriented COBOL is simply a set of compilers and rules that allow developers to create COBOL applications in modules that can trade or share functions, making it easier (sometimes) to change the applications once they're written.

Why haven't I ever heard of it? Because even most COBOL shops don't use it as a primary programming tool. Converting older COBOL code to object-oriented code would require more than just running it through a different compiler, according to freelance software architect and COBOLReport.com columnist Martin Pagnan. Object-oriented applications require a different structure compared to the linear "do this, then do that" structure of most COBOL apps, which would require almost a total rewrite of the software, says Jonathan Eunice, principal analyst at consultancy Illuminata, Inc. in Nashua, N.H. "COBOL is incredibly structured. And retrofitting an object structure to it? Well, you can bolt an internal combustion engine to a camel, but I'm not sure what you'd get out of it."

So why should I care? If your company is of any size, you probably have COBOL code running right at the center of your technological nerve center. Anything you can do to update it, make it more available outside the mainframe environment, or tweak it to reflect new business rules will help. That's why so many lines of new COBOL code are written every year. Most of that new code, and much of the maintenance work, takes advantage of some object-oriented techniques, according to Edmund C. Arranga, editor of COBOLReport and an independent writer and consultant.

So what's the downside? COBOL applications have always been expensive, and will continue to be. Most run on mainframes. Although it would be better if this software ran on cheaper servers, the cost of moving it is prohibitive. The number of skilled COBOL programmers is also shrinking and aging. But the Meta Group consulting firm predicts that 60% of mainframe applications will continue to reside on mainframes, which means that companies strapped for COBOL programming will have to rely on labor-saving tools and techniques like object-oriented COBOL to keep those old dogs running.

This article was first published on baseline.com.

Copyright © 2004 Ziff Davis Media Inc. All Rights Reserved. Originally appearing in Dev Source.