33

Even though we have languages like C++, Java, Python, etc., why is COBOL still a preferred language in the business world?

Why was it so popular?

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Prasoon Saurav
  • 85,400
  • 43
  • 231
  • 337
  • Can you source your information? Who says it’s still **preferred**? I know it’s still used but I have never heard any preference of it to a high level language. – vol7ron Apr 12 '20 at 17:06

11 Answers11

48

Code inertia. Huge amounts of existing code written in COBOL = prohibitive costs to switch everything over to another language. Wikipedia says there are over 200 billion lines of COBOL code in use.

Policy inertia. The places where COBOL is really in deep use tend to be government agencies and large businesses, which are notoriously slow to change.

Human inertia. People who make their living writing code and know many languages are less likely to consider it a big deal to learn a new one. People who learned one language because they needed to know it to perform what's otherwise a "business" job may not even think to switch.

Jay Bazuzi
  • 41,333
  • 12
  • 104
  • 161
Arkaaito
  • 7,189
  • 2
  • 36
  • 54
  • 4
    Indeed. I don't think “preferred” is the right word to describe COBOL really, it's just still here, seemingly forever. – bobince Jan 08 '10 at 06:02
  • 35
    That 200 billion lines number on the Wikipedia page needs a better citation than to a non-extant article on a webpage for a company that appears to derive its primary business from COBOL and uses phrases like "paradigm shift" on its webpage. That number is highly dubious; 200 billion is a gigantic number. COBOL has existed for 60 years. So on average that is 3.3 billion lines per year. Of course in the early years it could not be anywhere near that so I call b.s. This isn't really directed at you, just a general comment. Your answer is great. Plus one. – jason Jan 08 '10 at 06:16
  • 3
    add to this that COBOL is often used for critical business applications that few dare to make changes too (ie. bank transactions) – Christian V Jan 08 '10 at 14:08
  • 2
    200 billion lines is just because of the systems using cobol as intermediate code, and doing a bad job at that. – Stephan Eggermont Apr 10 '11 at 19:13
  • And now Java is the new COBOL. – Peter Mortensen Apr 12 '20 at 15:02
31

I'm not so sure COBOL is preferred by big business and government. I would say tolerated might be a better word.

Why?

  1. Because big government/business is risk adverse when it comes to managing their financial systems. Screw up here and the whole enterprise is put into jeopardy. If it ain't broke don't fix it.

  2. It is difficult to make a solid business case to replace mission critical systems containing millions of lines of code over what boils down to a "my language is better than yours" type of argument – ok its more complex than that but coming up with a solid business case is difficult.

  3. Transaction volume. COBOL applications tend to be optimized for throughput. Batch processing large amounts of data is where COBOL really shines. Java applications are somewhat harder to optimize for throughput because of the tendency to have more infrastructure layers between the program and the "metal" which adds processing drag. Big business/government have a lot of data to push through their systems and throughput is essential.

  4. Cost per transaction. COBOL generally has a lower cost per transaction when all factors are included. This is partly because processing time costs money, and COBOL applications are generally more efficient. However, COBOL applications seem to have lower development/maintenance costs too.

Before everyone jumps all over me for that last point let me explain...

I work in a very large shop and a few years ago an executive decision was made to build all new systems in Java. COBOL was going to be retained only for maintenance of the existing legacy software base. A complete phased out was planned for a 15 year time horizon.

Some of the best and brightest Java minds were brought in to train, set up Best Practices, build infrastructure and support for large scale Java development. This initiative was well planned and executed. Then, after a number of Java applications had been deployed the "bean counting" started. The results were that COBOL applications still cost less to develop, maintain, support and run - long hard number crunching here because the result was not welcome!

COBOL is back - but not completely. The new executive direction is to keep COBOL for heavy lifting (back end transaction processing) and batch oriented applications. Basically COBOL is to be used for number crunching and business rule implementation. Java comes to the front to provide GUI type interfaces and light-weight processing.

I suspect this is probably the industry trend. COBOL isn't going to disappear any time soon, but it may slip out of sight behind the scenes where it supports new players up front.

NealB
  • 15,862
  • 2
  • 34
  • 60
  • 2
    +1 for some information on the plusses of cobol from personal exprience. – Noufal Ibrahim Jan 17 '10 at 12:42
  • 1
    So why not FORTRAN or C for number crunching? – user Sep 28 '12 at 09:33
  • 9
    @user COBOL implementations usually have native support for packed decimal data types (COMP-3) which are ideal for fixed precision arithmetic commonly used in financial applications. Fixed precision math is often implemented through library functions (i.e. higher run-time costs) in other languages like FORTRAN or C. On the other hand, FORTRAN/C are still common language choices in the high performance scientific computing community because of their "close to the metal" support for floating point operations and fairly direct statement-to-machine-instruction compilation. – NealB Sep 28 '12 at 14:04
7

First - I work for Micro Focus - so I am an interested party. However, I would turn the question back on its self. Why not? The inherent assumption is that C++, C# or Java are naturally going to be better because they are newer. However, COBOL has not stood still. Partly because of its wordy syntax, it has proven possible to add new features to COBOL so it has remained competitive. People quite often talk about how 'bad' COBOL is, but are comparing 30 year old COBOL to the latest version of C#, Ruby, etc.!

Indeed, the very history of COBOL is evolving, but it remaining backward compatible is a strong reason for a business to invest in it; the TCO is reduced because there isn't any need to rewrite.

For more on the very latest version of COBOL - check out the community site for Managed COBOL:

http://knol.google.com/k/alex-turner/micro-focus-managed-cobol/2246polgkyjfl/4

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
alex turner
  • 1
  • 1
  • 1
5

Why did it catch on ?

Because in the late 1950's the US government decreed that if a software vendor wanted to sell an app or write an app for the government, the language had to be cobol.

As a consequence, for decades long it was the language that had the largest set of compiler vendors supporting it, and it was the language with the highest degree of ISO standardization, with only FORTRAN getting anywhere near that, but FORTRAN obviously had a completely different target audience.

Second reason : because even today, it is better than any other language I know for certain aspects of certain business problems that occur fairly frequently. The most important of these aspects is decimal arithmetic. Cobol has it natively (as is the case for PL/1 and such), but that is not true of any of those allegedly "more modern" langauges. Incidentally : that is the very reason why there are so many questions here regarding "what is the best data type for storing money values ?". The people asking those questions know no better than that the entire IT world consists of some OO language and some ORM tool, and have no idea of why such a thing a "money arithmetic" might be useful for a computer language to support it natively, i.e. for a computer language to have a built-in, native data type for it, other than bigint (with the programmer still having to keep track of the number of decimals), or float (with the programmer still being responsible for adding the correct rounding logic all over the place).

Erwin Smout
  • 17,245
  • 4
  • 28
  • 49
5

None of these languages offer what Cobol does -- fast, efficient processing large batches of data. It doesn't need graphics, it doesn't need bit-twiddling, it just needs to do what it does well -- accounting mostly.

C++ and C are ok substitutes for systems style stuff but they fall down on fixed point math and strong support for record oriented I/O. In the space where most financial and business apps live, z/OS, both Cobol and z/assembler have better native support for those things.

Java is good, safe, and workable. And on IBM mainframes, Java and Cobol interoperate very nicely. But some things that are easy to do in Cobol are very hard to do in Java, and the converse is true. They are complementing each other, not replacing each other. Java also does all it's fixed point math via library calls, which are much slower than native opcode support.

Python uses library (aka module) support for fixed point math as well as record I/O. It also suffers from a fatal, IMHO, design flaw of using indentation to delimit scope. This works reasonably ok in the relatively homogenous environment of Mac/Windows/Unix with some variant of ISO8859-1 character sets. It is prone to problems when moving back and forth between an ASCII-centric world and an EBCDIC-centric world where line terminators are not as simple as "\n\r, \r, \n" and any misconfiguration in a file transfer package, character conversion routine, or editing by a terminal configured for a different character set will destroy the scope of your source.

All of the languages you mention have weaknesses in critical business needs where Cobol is the strongest.

Joe Zitzelberger
  • 4,168
  • 1
  • 26
  • 40
3

It works on machines that can hotswap any piece of hardware, and degrade gracefully if a processor dies. Reliability is everything when working with billions of dollars.

Those machines also support ridiculously large I/O speeds; if you can't handle a day's worth of transactions in real time, you're out of business.

It's been a stable language with very few deprecated bits since 1985.

The code isn't easily ported to another language, because developers didn't "plan" for that to ever happen. Moving the code that's powering systems today to another language is a risk and a very large cost.

Reliability counts for something, and COBOL has it in spades.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Dean J
  • 35,669
  • 13
  • 61
  • 92
  • 2
    Solid reliability is often vital. Ask someone whether they want their bank account controlled by technology that has been made rock solid over many decades, or by the coolest offering from the language-of-the-month club? (Yes, I know there are other reliable languages, but I'm just making a basic point). – WarrenT Jul 27 '12 at 20:30
  • ..and not having to re-write everything every five years has enormous benefits. Let's look in on some enterprises that moved to Visual Basic, oh dear...... – mckenzm Oct 12 '20 at 01:35
2

Why did it catch on?

It was heavily pushed by IBM. This was a great help for Fortran and COBOL, although not PL/I.

It was available very early on, first appearing before 1960.

It was a lot easier than using assembler, even IBM System/360 assembler (which was a very nice one for business processing). It picked up a lot of people trying to do better than assembler.

It was a very good match for common business computing practices of the time. It was very good at accepting input, doing minor transformations, and spitting out reports. (It still is, for that matter, but businesses have far more diverse needs nowadays.)

It had some special features, such as decimal arithmetic while keeping track of decimal points, and record data types, that worked very well in business.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
David Thornley
  • 54,186
  • 8
  • 87
  • 153
1

[Vendor Post - but not necessarily the vendor's official statement]

There is certainly inertia, an install base, and risk of change are very valid reasons, but I would say there are good reasons within the language itself. If you want to do batch processing of large sets of data records or want to do financial calculations then the definitions of record layouts and numeric data types are better than any other language.

As NealB describes in his post, I've spoken to users whose natural environment and expertise is Java, but they keep the core logic in COBOL because it's the best tool for the job. They liberally mix Java (primarily for Unicode string manipulation and systems integration) with COBOL within the same application. If they compared the amount of code to do the same work in Java it just didn't make sense. Alex Turner has posted some great examples on another website comparing typical business functions in COBOL with Java.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Mark
  • 554
  • 3
  • 4
1

I worked ao c , c++ and java too. all are advance n having grafical feature. But when matter of Computing comes, means no hard works only business calculations and speculations. no one beat COBOL in efficiency.. and Huge data procesing, Prossesing for a day or more then a day .. in Java or other language !!! forget. its only cobol and mainframe.

  1. the bleach of security. there is no bleach for last morethan 60 year in mainframe.
  2. simplicity of code to handle in emergency or showstoper situation.
  3. hey use front end in java,vb.net all, but for data keeping the rely on DB2.so cobol became must.

its all resons why leading banking firms thinking 10 time before migrate from mainframe to other.

j0k
  • 21,914
  • 28
  • 75
  • 84
TAps
  • 35
  • 1
1

Many big companies, especially banks, have complex systems written in COBOL, which just simply work. Rewriting and designing such systems is observed by many such institutions as being a waste of resources including time and money. There's also the risk that certain requirement-specific features may be lost along the way. Hence the age old expression, if it ain't broke - don't fix it.

Dot NET
  • 4,828
  • 11
  • 49
  • 94
0

Cobol was invented to allow people who knew nothing about computer to write programs. This is exactly the kind of bad idea upon which Business, particularity American business thrives.

Good software requires high skill and good tools some of which will actually require real knowledge and understanding to use at all let alone well. High Skill levels tend to demand high pay, thus the search for the sliver bullet continues and high skill is actively discouraged. Don't believe me? Try these links

http://userweb.cs.utexas.edu/users/EWD/transcriptions/EWD12xx/EWD1284.html

MG1
  • 35
  • 2