Is Your Next Language COBOL?

Don't count Cobol out. It's a key element in modern distributed business software architectures.


September 18, 2008
URL:http://www.drdobbs.com/tools/is-your-next-language-cobol/210602491

In July, citing a budget shortfall, the Governor of California ordered the salaries of 170,000 State employees to be cut to the Federal minimum wage.

Not so fast, said the State Controller. Because California's payroll systems are written in antiquated Cobol code, it would take six months to implement the change and nine months to restore salaries later. That's if we had the Cobol programmers to do the job, which we don't, because you fired them last week, Governor. And we can't hire them back because nobody's going to take a pay cut from Social Security to program Cobol for minimum wage.

Government is our favorite spectator sport.

Blame Cobol

It may seem surprising that it takes any programming at all to implement a salary change in a payroll system, but a commenter on Slashdot said it was at least plausible, and that's good enough for us. What is not surprising is that Cobol would get blamed. Cobol is the most reviled programming language ever created.

On Dr. Dobb's CodeTalk blog this summer, Walter Bright said, "Programming languages are developed by programmers for programmers. This is as it should be. The last language developed for management was Cobol...I've never heard a nice word said about it."

There have been plenty of the other "kind" words spoken about this nearly 50-year-old language, though. The Turing Award-winning computer scientist Edsger Dijkstra famously said, "The use of Cobol cripples the mind; its teaching should, therefore, be regarded as a criminal offense." Perl creator Larry Wall made his loathing more specific: "I knew I'd hate Cobol the moment I saw they'd used perform instead of do." Pulling no punches, the Jargon File informs us that Cobol is "a weak, verbose, and flabby language used by card wallopers to do boring mindless things on dinosaur mainframes," adding that Cobol is "synonymous with evil."

And it's no fun, either. "As a programming tool," Charles Petzold once said, "it has roughly the sex appeal of a wrench." Small wonder Cobol has few ardent enthusiasts. Pretty uncomfortable to be a Cobol programmer today, then, especially since "Cobol programmers are destined to code Cobol for the rest of their lives," as Bertrand Meyer has said, "and thereafter."

So if all that is true, isn't it strange that Cobol: 1) is the most widely used language in the 21st century; 2) is critical to some of the hottest areas of software development today; and 3) may be the next language you'll be learning?

Cobol, The First 50 Years

In case you need to be reintroduced...

Along with Fortran and Lisp, Cobol was one of the three seminal programming languages created in the 1950s. Developed in 1959 by a team led by Grace Hopper and approved in January 1960, Cobol is characterized by a verbose English-like syntax and a strict hierarchical program structure. The language standards specify the handling of decimal currency data more fully than any other language. Cobol was designed for business data processing and remains the quintessential language for that purpose. (Cobol is an acronym for "COmmon Business Oriented Language.")

The Gartner Group has "maturity-rated" all programming languages as:

By Gartner's definitions, current Cobol variants are not, as you might think, Elderly, or even Aging, but merely Mature.

Hopper handed over governance of the language to ANSI, which helped its wide adoption. The current Cobol standard is Cobol2002, supported by, for example, IBM's Enterprise Cobol (www-306.ibm.com/software/awdtools/cobol/). Cobol2008 is in the works.

A Quarter-Trillion Lines of Code

To say that Cobol is widespread is an understatement. In 1997 the Gartner Group estimated that there were 240 billion lines of Cobol code in active apps. Something like 90 percent of financial transactions are processed by Cobol code, and 75 percent of all business data processing is Cobol. Merril Lynch reports that 70 percent of its business runs on Cobol apps. Five out of eight companies with an IT manager use Cobol, most of them using it a lot. One estimate puts the value of current running Cobol code at $2 trillion. (In addition to the Gartner Group, some of the above figures come from Computerworld, Ovum, and Micro Focus International.)

And it's not just legacy code. Billions of lines of new Cobol code are being written every year. Cobol apps are typically very large, a million lines being common, and partly for that reason they are also long-lived. It's cheaper to maintain the code than to replace it, and 40-year-old Cobol applications are often extremely well debugged (although anyone who was bit by the Y2K date bug, primarily a Cobol problem, might disagree).

Cobol Coders An Endangered Species

In fact, the code is outliving its coders.

As long-time Cobol coders die or retire, they are not being replaced. Few schools teach Cobol any more. And demand is still strong. If your business depends on Cobol, you are facing some choices. Whether you're actively developing new Cobol apps, just maintaining the old, or trying to move away from Cobol, you need Cobol expertise. You can: 1) keep your current Cobol programmers happy and employed while you scramble to wean your business off Cobol; 2) try to find younger Cobol programmers to replace those you'll be losing; or 3) push your current programming staff to learn Cobol.

Replacing Cobol entirely can be an expensive proposition, and many companies (and State governments) have for decades thought it cheaper to keep it. Still, many businesses are moving away from Cobol, or saying that they will if and when they can. Some big companies are replacing at least some of their legacy Cobol apps with packaged software from Oracle and other companies. But a quarter-trillion lines of code does not get replaced overnight. Cobol programmers are needed.

Micro Focus and IBM have tried to nudge universities to train more Cobol programmers, offering free courseware and technology, but this hasn't resulted in a huge flood of new Cobol programmers.

So adding Cobol to your toolkit does make you more employable. And you can definitely do better than minimum wage.

Not Your Father's Cobol

You'll find, if you decide to take a look at Cobol, that it has become in many ways a truly modern language. The 1985 standard introduced structured programming and the 2002 standard gave Cobol object-oriented capability. In 2005, Ralf Lammel and Kris De Schutter demonstrated that even classic, preobject-oriented Cobol, was well suited for aspect-oriented programming (homepages.cwi.nl/~ralf/AspectCobol). Modern implementations demonstrate that Cobol can play well with other languages and technologies on their playgrounds.

Nevertheless, Cobol is still verbose, still very 1959 in its syntax, still—Cobol. Is there any way to make programming in Cobol sexy? Author and Cloud Architect Lewis Cunningham says, Yes, if you make it run on a JVM.

That's what Veryant (www.veryant.com) has done. Its Cobol Application Platform Suite translates Cobol source, written in a GUI on your preferred platform, into Java classes that are executed with the Java Virtual Machine. The Cobol Runtime Environment is implemented in Java, making the code highly portable. Cunningham says, "I hope I never have to code Cobol again. But if I do, I would at least want it to be portable."

Porting Cobol code can be a huge task, but Cobol itself may be the most portable programming language. The Eclipse Foundation has a project to develop a fully functional Cobol IDE for the Eclipse platform (www.eclipse.org/cobol). "Our focus," they say, "is Cobol application development on Windows/Solaris/Linux for deployment on each platform." And IBM, Microsoft, Fujitsu, Micro Focus, and Veryant are major players in making Cobol maximally portable.

Micro Focus (www.microfocus.com) produces nonmainframe tools for understanding, porting, and developing Cobol code, and products that support native implementations of CICS, JCL, and IMS DB/TM on Windows, UNIX, and Linux. Micro Focus embraces the "own dogfood" principle: Gary Crook, Micro Focus's Worldwide Vice President, Product Development, says, "the very core of our product set, the Cobol compiler, is itself written entirely in Cobol and we use our own Cobol for the development of new features and products."

Last year, Micro Focus and Microsoft announced a strategic relationship to help businesses modernize Cobol apps by porting them to the Windows platform, so a lot of Micro Focus development happens in the world of .NET, J2EE, and Web 2.0. Micro Focus's Cobol implementation within .NET, Crook says, "is on a par with any other .NET language in terms of capability."

All this, Crook says, adds up to making businesses more agile in squeezing value from their IT assets and delivering more value to the business. For this reason, Cobol "will continue to evolve by retaining a simple focus on delivering agility to the market."

And what is sexier than agility?

Cobol, Gateway To the Web?

But there's a sexier reason to learn Cobol than just to maintain or port old code.

Cobol is a key element in the realization of modern distributed business software architecture concepts—XML/metadata, Web Services, Service Oriented Architecture—and e-business. Not a trendy element, or you'd see Cobol sessions at the next Web 2.0 conference. But a crucial element. Lemmel sees the essence of metadata in Cobol's IDENTIFICATION and ENVIRONMENT sections and of Web Services in its CICS transactions.

The very concept of a Cobol application is something of an oversimplification. Cobol programmers work with a collection of technologies tied together in ways that have some similarities to SOA models. Scott McMahan in an e-mail says, "If you want to understand modern Cobol, it's a glue language. IBM has a 'stack' of technologies for data processing like CICS, DB2, IMS, VSAM, ISPF, etc., which are glued together using Cobol."

The role of the Cobol programmer in moving from traditional implementations to web-based models can take many forms.

The programmer may bridge between Cobol code and new apps, which requires understanding Cobol, the business rules underlying legacy Cobol code, and modern languages and systems. With the emergence of SOA and IBM's Language Environment, with its common runtime environment, existing Cobol code can be integrated with other code more easily.

The tools available for integrating Cobol and the Web are evolving quickly. Veryant is making it possible to do Web 2.0 development directly in Cobol: "the same graphical resizing of windows that is part of most Web applications today is now easily implemented for Cobol program end users." Micro Focus, through its partnership with Microsoft, is developing strong SOA support for Cobol app development. And Fujitsu considers its support for allowing Cobol programmers to program directly to the Web "several steps forward" beyond migrating code. You can, for example, embed Cobol code in ASP+ pages or write Web Services directly in Cobol.

"This is the quiet reality," Crook says, "the business world runs on Cobol [and] Cobol today is a very modern language that continues to leverage its historical strengths for delivering new value to the business fast."

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.