The unmentioned parts of COBOL's history

Question

I'm very curious about old programming languages, especially COBOL, and as Wikipedia couldn't really tell me much about this topic, I decided to ask it here:

• Was COBOL the first programming language really being used in financial, stock and banking systems?

• Where exactly was COBOL used?

• Was it used more frequently than Fortran or BASIC, for example?

• I don't know if you lived at that time, but how did people react to the rising COBOL? Did they expect it to be the future?

• When has COBOL actually stopped being used to create new, big systems?

• Are you sure that there are still important legacy apps written in COBOL out there? I can't believe that somehow.

Answer 1

1. No idea really, but LEO was used for payroll. It used a language similar to COBOL called CLEO.

2. COBOL is used all over the place. Mostly banks and big mainframe departments.

3. difficult to say. It was certainly popular back in the day.

4. Back in the days when COBOL had its heyday, the alternatives were for alternative niches - eg Fortran for scientific, Algol for academic, Cobol for financial. Did they expect it to be the future... possibly.

5,6. It still is used. Search for COBOL jobs, you'll get quite a few hits for banking and financial companies that are looking for programmers, architects, etc. Pays quite well too by all accounts.

Answer 2

Previous SO questions have gone a long way toward answering your questions. Please review:

What are Fortran and COBOL used for today

Why is COBOL still a preferred language in the business world

Reasons to start a new project in COBOL

What makes COBOL such a hated language

Was COBOL the first programming language used in financial, stock and banking systems

Well known languages that co-existed with early COBOL are Fortran and Lisp. These languages were not much used much outside of research and university facilities.

The landscape was highly fragmented within the world of business computing. A number of proprietary low-to-medium level languages existed but generally only ran on one vendors machine. A few examples were: FLO-MATIC, AIMACO and COMTRAN, all of which heavily influenced the development of COBOL.

From this chaos emerged a strong desire to have a machine independent and common language for developing business applications.

According to Jean E. Sammet (The Early History of COBOL), the US Department of Defense spearheaded and funded the early development of COBOL.

Where is COBOL used

Largely in financial (banks/government) and insurance industries. Outside of these sectors, COBOL is pretty much unheard of.

Is it used more frequently than Fortran or BASIC

I believe Fortran actually pre-dates COBOL by a little bit. Fortran is primarily suited for high-performance numerical applications (astronomy, physics and the like). COBOL is primarily suited for financial and record keeping applications - the stuff of business and commerce (hence the name: *CO*mmon *B*usiness *O*riented *L*anguage). The two were never in "competition" so asking which is more frequently used is kind of like comparing apples to oranges.

Putting the "apples" and "oranges" aside, it is hard to say how many lines of production code exist for either of these languages. Estimates vary from billions to millions. However, I don't think anybody would claim that the active code base is insignificant.

BASIC (excluding "Visual Basic") was largely a personal computer language. There have been a few ports to larger machines (eg. VAX BASIC - Oh that was fun) but I don't think this ever caught on. I would be surprised if there are any significant production systems written in BASIC today. Just say "BAISC" to any "old timer" and their minds will flood with fond memories. Other than that it is pretty much gone.

When did COBOL stop being used

The COBOL legacy is huge. As such, there is a lot of legacy maintenance going on today, and it will go on for many years to come.

Is there any new development? I would say less and less every year but it is nowhere near coming to an end. I work in a very large shop and we actively develop new COBOL applications. I don't believe we are alone. Those that still actively develop systems in COBOL are not a bunch of "back woods" idiots who don't know any better. They do it because COBOL "delivers the goods" for the least cost per transaction processed. Believe me, if any other technology could do it cheaper, faster and more reliably, COBOL would be gone tomorrow!

One can only get an appreciation for how wide spread COBOL is by working in the financial, government or insurance industries - and then only in an area where they have to push a lot of data around. If you work outside of this environment it is like the language died a hundred yeas ago!

How did people react to the rise of COBOL?

In a couple of words: Not well.

COBOL came into existence just about the same time that the academic world made huge breakthroughs in language theory and compiler design. COBOL missed that boat and has been denigrated by everybody with an academic interest in computing ever since. I went through university in the 70's and even at that time the word "COBOL" made us all cringe. The hate for COBOL runs very deep.

Even the developers of COBOL could not have predicted the long term success of the language. The original COBOL was specified by a "short range committee" so that could it implemented with reasonable time and effort. The final "touches" would be made by a "long range committee". The "long range committed" never materialized and this is what we got!

The death of COBOL has been predicted as imminent since the 60's. It is still with us and going strong.

Why? I think there are three big reasons:

• Code stability. COBOL carries its legacy fairly well, major upgrades are rare. This may not be a selling point if you are in the business of developing code. However, if you are the one paying for it COBOL gets high marks on this one.
• Performance. COBOL applications are generally developed where volume and/or throughput are critical (eg. processing monthly bank statements, tax returns, etc.)
• Track Record. Organizations that use COBOL generally know their track record. They have a certain comfort level with cost/time estimates for major development projects using COBOL and related technologies. Taking on a new language and supporting technology to implement mission critical applications involves additional and unknown risks (and unknown benefits).

Notice that all the reasons I have cited for COBOL's continued existence are driven by cost and risk minimization. There is nothing from a developer's point of view that makes developing in COBOL interesting. Blame corporate accountants for COBOL's continued success.

On the brighter side, there are a few frameworks (eg. Bassett Frame Technology and XVCL) that can make COBOL development today tollerable, even, dare I say, interesting.

Answer 3

Answering the last part:

Yes, there are certainly new COBOL applications being written at banks everyday. Large financial institutions usually have a mainframe or two around, as they (traditionally) have a much better uptime than standard servers, and can move a lot of data reliably.

Additionally, the people still doing COBOL are pretty darn good at what they do.

If you're dealing with billions of dollars of electronic transactions, reliably is worth paying for, even if it's not new or sexy to do so. Then again, I can't hotswap the processor out of my webserver; hotswapping any of the parts out of a mainframe is usually possible, and that's actually a pretty tech-sexy feature, if I gotta say so myself.

Answer 4

Was COBOL the first programming language really being used in financial, stock and banking systems?

For practical purposes this was all done in assembler, but Cobol was the first high level language to move into these domains.

Where exactly was COBOL used?

Any place where money changed hands, inventory was tracked, et al. Your use of the word "was" implies that it is not now used. Cobol is involved every time you swipe a credit card, ship a package, make a phone call...it is every where. Still.

Was it used more frequently than Fortran or BASIC, for example?

Yes, very much so. Fortran is well geared for science geeks and engineers -- a noble calling -- but they don't exist in the numbers of the sales and marketing geeks, the Cobol domain.

Does anyone use BASIC? Doesn't that suck?

I don't know if you lived at that time, but how did people react to the rising COBOL? Did they expect it to be the future?

People like credit cards. People like online access to their bank accounts. People like Voice Response Systems that give their balance and last 5 transactions. People like ATMS. People like fast airline and hotel bookings.

The only people who don't like what Cobol does for them are programmers that have never put the time and effort into understanding Cobol (but they hate it anyway).

When has COBOL actually stopped being used to create new, big systems?

Ummm, never. Cobol is still actively developed and used all over the world. It isn't sexy and no Computer Science professor is going to tell you that it is "the next big thing" -- but if they knew what they were talking about they would be making money in the real world...

Are you sure that there are still important legacy apps written in COBOL out there? I can't believe that somehow.

MasterCard. Visa. Naa...

Answer 5

RE code stability of cobol: Updates rare, but they are very disruptive, and are actively resisted by the installed base. When forced, conversions often are done in a compatibility mode and the testing alone can burn the entire SD budget for a year. OO cobol is a case in point as the real costs of conversion will exceed its benefits unless a total redesign is attempted. Consulting shops love this as they bill for time, but for the organization it has the potential to literally put them out of business. One of the great myths of this OO cobol exercise is the 'portability' of the skill set of cobol, but in fact it is the OOP/OOD skill which is lacking and must be taught to the legacy programmers. Learning a new paradigm is allays harder than learning a new tool ( language) and in point of fact the exercise makes no sense and is entertained only by that bastion of folly known as management ---as carefully mislead by the vendor community devoted as they are to the creation of 'value' for their shareholders. It is often an easy sale, and fools generally do deserve to be fleeced.

RE execution speed. This is not really worth a detailed response. Platforms are fast, and it is compilers that determine execution speed. I have examine the asm output from COBOL compilers and it is not any better than a good c compiler. More to the point classic COBOLS's lack of type safety , failure to support scope, failure to support parametrized procedures, failure to support explicit type conversion etc, leads to the mistaken impression that because it does not do any of this it is faster. In fact most of this requires only compile time support and the rest does not add much overhead ( and what little it does can be optimized out) where as it does make code reuse prohibitively expensive, make testing a nightmare, and produce brittle code.

It will only go away when it costs to much to fix. This may or may not happen, but it is more likely that the organizations will fail due to a major software issue which would have been trapped by a type safe language before then.( OOP will provide type safety but that will require that cobol programmers and business analysts learn to use types)

Answer 6

I managed to go almost 15 years in my career without touching a single line of COBOL, or even of seeing it. Until I got my last job, which is some enterprise middleware that links COBOL to web services and non-mainframe databases. My very first customer engagement at this new job was with a big-ass company with lots and lots of COBOL they wanted to integrate with newer systems.

Learning it has been a pain, mostly because there are few good PC-based COBOL engines left, but it's not really hard at all. And that is why it's still around. It does a job, does it well. It's showing it's age a bit in how it interacts with SOA frameworks, but even that problem is going away.