A question about COBOL!


my name is Norman, im currently doing a research on cobol,

the topic is "Is COBOL dead or is it still useful?"

im totally new and dont know anything about cobol, currently, the only thing I know is that it is a programming language for bussiness.

Can someone tell me what is the problem with COBOL? why does some people thinks its dead and if its still useful in what area?

or if some of you can find me some useful links please let me know..

thanks very much,

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Cobol's not dead

At AOSD'05 there was a talk that started with the role of Cobol today, see the first slides at http://homepages.cwi.nl/~ralf/AspectCobol/slides.pdf

But is is, FTMP, a legacy language

Design starts in Cobol (I believe nowadays the first-letter-only-capitalized spelling is considered more "correct") aren't very common. When Cobol is used in production; almost always it is because the project in question has to support/interface with legacy code that's written in Cobol.

Other than interfacing with existing Cobol deployments, I can't think of any reasons to choose it for a new project.

Purpose Built

Nowadays you'll find some folks with Object COBOL compilers for sale, but they're only used for extending additional code. The problem with COBOL (besides the lack of brevity in the syntax) is that there's a lot that the language doesn't do without jumping through many hoops. I've written a heap manager, red-black trees, a virtual filesystem, etc. in COBOL, and it wasn't any fun at all. COBOL is cursed by the fact that it was designed to do one thing, and to do it very, very well: record processing. Back in the bad old days when everything that banks did happened in overnight batch processes, you'd upload a file containing a gazillion records to a server, and it would cruise through these records doing whatever needed to be done with them. The language treats record fields as native variables, so the record-processing programmer can just code up the calculations required (which often involved pumping out new records into other files for further processing). In the modern world of J2EE & .NET there is still call for big batch processes, but nowadays many of these are performed inside of relational databases instead of flat-files.

As Mr. Ostermann above says, it's not dead, but unless you're looking to do what COBOL was designed for, there are probably a lot of better tools for the job.

I think a fair number of telephony billing systems were written in COBOL too, btw, since 'call records' that are spooled from telephone switches tend to have fairly standard formats, but I don't know if a lot of these systems are still around or not.

Hope that helps!

COBOL isn't dead, but it should be

As an ex-COBOL programmer, I feel the language should die a violent death. I've written about some of the problems with COBOL, but much of language design has stemmed from economics.

When COBOL first came out, computers were expensive relative to programmers, so the more work you pushed onto the programmer, the better. Today, you can buy high-end computers for less than a programmer's monthly salary. Thus, languages which decrease a programmer's productivity tend to be less success successful from a financial standpoint (of course, this is an oversimplification. There are many other factors involved.)

Part of the reason why we still have COBOL, though, is that large corporations have multi-million dollar systems which cannot fail. Thus, experimenting by migrating to a newer language is a dangerous proposition even though it's becoming more and more imperative.

Perversely, one of the reasons enterprise class systems written COBOL were so successful is because of how primitive the language is. Because it can't do much (you typically call up another job to do sorting, for example), COBOL programs tend to be small, discreet programs that do one thing and do it well. Then they're put together in pipelines by JCL (Job Control Language) which controls the flow of behavior. One program will read the data and write some files. The next program will sort one of the files. Another program will read the sorted file, add a couple of fields and shove the records in a database. Another program reads the database ...

Because no one piece does too much and because well-defined interfaces are mandatory, COBOL -- particularly in batch environments -- tends to be successful. With newer languages where you can do everything in one program, people often try to do everything in one language and fail miserably (which is where automated testing comes in, but I'll stop now.)

not exclusively COBOL

COBOL programs tend to be small, discreet programs that do one thing and do it well. Then they're put together in pipelines by JCL (Job Control Language) which controls the flow of behavior.

So, there it is: the origins for the pipelined batch processing on *nix systems! And from there, to Perl. :)

Because no one piece does too much and because well-defined interfaces are mandatory... tends to be successful

But that's not a feature from COBOL nor from the *nix way: it's a staple of good design practices. I've always learned: KISS, "small, few interfaces" etc.

With newer languages where you can do everything in one program

I don't think it's necessarily bad to write all of a system in one language, in one program, though perhaps you'll be losing a lot of opportunities and flexibility from not going multi-tool, multi-paradigm.

If your java program is constituted from lots of small, clearly modular classes with a few, small methods, it's better than a fullblown monolithic class with a main method making everything happen. And you can make a parallel between small COBOL programs pipelined by a JCL program and java classes message-passing handled by the JVM...

what's better: lots of little specialized snippets of code in various languages interfacing together to form a whole system ( like most web systems today with SQL, XML, javascript and some server-side scripting ) or a huge, though modular, standardized environment written in one language alone ( ala the links proposal )?

i think there's room for both approaches...

I wasn't meaning to imply tha

I wasn't meaning to imply that one shouldn't put everything into one program. If that's what makes sense, that's fine. However, as one program/lannguage/system tries to do more, you increase the chances for bugs and this was the reason for my side comment about testing.

But that's not a feature from COBOL nor from the *nix way: it's a staple of good design practices.

Ordinarily I would agree. In the case of COBOL, this is an accident. I've worked on COBOL code written before I was born and frankly, much of the understanding we have about modular programming doesn't appear to have been as widely applied in the sixties. It's not that COBOL programmers said "let's create a bunch of cohesive, loosely coupled building blocks." I believe that, to a large extent, language, CPU and memory limitations backed them into this corner. If they understood good design, Dijkstra's "GOTO considered harmful" paper wouldn't have been necessary (or controversial).

Any new lines COBOL still being developed?

Thanks for the information guys,

Is COBOL still developing new lines of code? or is people just re-engineering legacy systems that was developped using COBOL?

Would a company use COBOL for a new system? why?


New COBOL is being written all the time. I've my fair share out there (I hate to admit). Most of this, I suspect, is to support new integration with legacy systems, but it's hard to say if that's really true without a comprehensive survey.

I'm not sure why any company would bother to use COBOL for a new system. Having programmed in "dinosaur" languages and graduated to Perl, Java and Prolog, (the latter possibly being a "dinosaur" language), I cannot imagine why anyone would start something in COBOL. While it was brilliant for its time, it's too primitive to be of use today. It has no scoping, it doesn't deal with free-form text and no namespaces. In fact, you don't even really have subroutines. You have sections and paragraphs, but they don't take arguments and they don't return values. In modern terms, they're little better than a GOTO statement (though I type most of this from memory and I idly wonder if some of my details are off.)

COBOL Has Changed A Lot

Some of you must be real dinosaurs: for years now mainframes have had transaction monitors like IBM CICS and Unisys TIP, which allow interactive applications (much like the WWW), relational, hierarchical, network and object-oriented databases. Batch processing is still done. But nowadays mainframes running COBOL _are_ web servers. The code is often the same COBOL code that ran the green screen displays; only a recompile was necessary to change protocols.

I was surprised to read that 15% of new applications are written in COBOL (Stop Bashing Cobol referenced earlier). Ralf Lämmel's home page has lots of info about COBOL and lots more about analyzing languages and extracting information from source code.

No satellite minis?

But nowadays mainframes running COBOL _are_ web servers

Do you mean literally, mainframe serving HTML??
Last time I worked with them (Unisys, 1998), it was prohibitively costly to use mainframe for such lowly task. There was usually a mini computer (or even a bunch of PCs) that served as a buffer between the crazy world and a serene mainframe. Though yes, I remember some Cobol tool (MicroFocus?) marketing some API for web programming in Cobol... Well, minis and PCs can run Cobol as well :-)

I want context for that quote

15% of all new applications are written in COBOL? I read through the slides but I still don't believe this. I would love to see the Gartner group study that provided this "statistic" and the context of that statistic. COBOL is still being actively developed for larger companies on in-house projects to integrate with legacy systems, but when's the last time you heard the "buzz" about the hot new COBOL app hitting your desktop?

A Few (More) Good things about COBOL

Few modern languages have these features, which are very useful for business applications:
  • fixed-length strings - memory efficient, fast and bugs are easily spotted,
  • fixed-point math - ideal for accounting.

P.S. to Ovid: you make COBOL sound very much like UNIX processing with pipes: small programs with a single purpose, chained together with a job control language. That remains a successful paradigm today in both mainframe and UNIX worlds.

Mainframes as web servers & COBOL Desktop Apps


Both the classic green-screens and HTML pages are text messages with control filler. Why surprise that a mainframe could serve HTML? Developers use (among other things) screen generators to generate procs/subroutines that encapsulate COBOL I/O. Vendors added HTML to the output formats. The addition of TCP/IP (achieved years earlier) was necessary first.


Among the reasons for lack of "hot new COBOL app hitting your desktop":

  • the desktop metaphor is dead - Servers rule!,
  • Interactive COBOL apps have always been server-centered; the only change is that today they're web servers. So you won't see the hot COBOL apps on your "desktop" - they'll be on the WWW.

COBOL's Achille's Heel

Right off the bat, the problem I see here is that one of COBOL's greatest weakness has been in text manipulation. I was working on one bit of COBOL that took comma delimited records from an NT server and transformed them into fixed-width records more friendly to COBOL. The code was 150 lines long, but that's because the author didn't understand how the unstring function worked. I got it down to 80 lines of COBOL. Out of curiosity, I tried it in Perl and got it down to 10 lines of clean, readable code with error checking.

Mind you, that's not particularly an argument in favor of Perl. Heck, even Java's verbosity wouldn't match that of COBOL's in this instance. Most modern languages would handle this with less code and from an economic standpoint, languages that allow the programmer to write more code in a shorter time (assuming the code is correct) are a better choice. I don't believe there are COBOL programmers anywhere who could match my speed of development. I'll smile and move my programs into production (with full test suites) before the COBOL programmers have their first compile (hell, I might even get done before they're finished typing in their working storage definitions.) Ignoring the economics of programming is a bad idea.

Update: I just realized how incredibly arrogant my statements about my development speed sounded, particular given that I suspect few people here have any idea who I am. So let me apologize if I come off sounding conceited. I don't mean to. I do, however, stand by those statements.

As has been pointed out befor

As has been pointed out before, COBOL comes from a time when computers cost more money than programmers. Back in those days, PhD geniuses with motor disabilities slowing down their ability to type would probably have been more economical than the iron running their code. Ignoring the economics of programming is a bad idea.

COBOL language design

The most off-putting thing about COBOL for me is its syntax, which I would call indefensibly verbose if it weren't for the likelihood that this would provoke some COBOL programmer somewhere into trying to defend it. I tried to learn COBOL a while back and gave up pretty early on, concluding that if I ever needed COBOL code that badly I could probably knock together a Python script to write it for me. (To paraphrase Harrison Ford's complaint to George Lucas about the script of Star Wars: you can type that stuff, but you sure can't think in it.)

Still, syntax is only skin deep, and from what others have said about the similarities between COBOL flow control and the piping-together of Unix processes, it seems that there is after all a COBOL way of thinking. The longevity of COBOL applications written before COBOL expanded its horizons with Cool New Features suggests that working within the limitations of the original COBOL programming model can make for robust and maintainable code.

I wonder whether it isn't worth thinking of COBOL as a kind of DSL, specialized to the task of building high-reliability business systems in a mainframe environment. The question would then be not what does COBOL lack that other general purpose programming languages have, but what would a good replacement for COBOL look like? What are the design issues around creating a language specialized to COBOL's domain - what does COBOL get right, and what could be improved upon?