• Please review our updated Terms and Rules here

What makes COBOL well suited for commercial applications?

cjs

cjs

Veteran Member
Joined
Nov 5, 2021
Messages
1,324
Location
Tokyo, Japan
In another thread some folks touched on the "rubbishing of COBOL," and @thunter0512 mentioned that:
thunter0512 said:
There are many who have never programmed in COBOL but happily rubbish the language. It has its flaws but is very well suited for commercial applications, which explains why the bulk of the finance sector is still using COBOL in their back-end systems.
Click to expand...
I've never written any COBOL, just read it here and there, and it doesn't strike me as a very good language due to its verbosity. (Then again, I'm a rather experienced programmer; plenty of people seem to think that verbosity isn't a problem, or is even good for the vast majority of lesser-experienced programmers out there—see Rob Pike on Go for more on this sort of attitude.)

I have written plenty of commercial code, including several financial systems, ranging from accounting for ISPs to trading systems. I can't really imagine using COBOL for any of those.

So what is it that makes COBOL good for commercial applications, and is that as applicable today as it was back in the '60s and '70s? Is it really the case that the bulk of the finance sector is still using COBOL in their back-end systems? (I've never seen any.) And are they using it because it's good, or just because it's legacy software that would be expensive and error-prone to replace?
 
I did write a little COBOL, using punch cards of all things, just to be able to say I did. Being a "hard core" programmer - even by that time - I did not appreciate the verbosity. I think that it was an early attempt at a "natural language" computer interface, in the sense that a relatively inexperienced computer person could read the program and have a pretty good idea what it did. And possibly even modify it successfully or even create new programs.

In the quote you reference, I'm not sure what they meant by "commercial applications". That seems like the wrong term. "Commercial" to me means anything being produced for sale (vs private software written in-house for use in-house), and it was definitely NOT the case that COBOL dominated software that was/is being sold. Back in the old days, source code was not made available to customers so it really didn't matter whether a software/hardware vendor wrote their software in COBOL, FORTRAN, Assembly, whatever. COBOL compilers were being sold, in my opinion, to facilitate computer installations that did not have deep skills in (low level) computer programming.
 
COBOL had the DB built in. ISAM tables and indexes were first class citizens in the language. It had BCD math built in. It was a simple language, that had a lower barrier to entry with its english like syntax. It had built in reporting and formatting. It was "Business oriented", and by that, most business style work is ETL style workflows, "extract, transform, load". Batches of data coming in, tables loaded, batches of data loaded from tables, and printed out on paper.

It does that shockingly well. BCD data stored as text, easily converted to and from an internal format (in contrast to floating point). COBOL can be quite efficient.

You can do that in FORTRAN, but FORTRAN is more complicated with a bunch of facilities not really important to business processing. Plus there was no BCD math in FORTRAN.

Finally, you had companies that built their machines and OSes around COBOL style processing, which made it more the "right tool for the job".

The real curiosity I have is why it was usurped by BASIC. In the mini world, BASIC was king. BASIC was everywhere.
 
whartung said:
Finally, you had companies that built their machines and OSes around COBOL style processing, which made it more the "right tool for the job".
Click to expand...
Heck, for the military, we had a multi-computer setup with the MOVE verb rules built into the OS. (It was complicated, but you could MOVE (or ADD, etc.) data to another program not actively running or present in main memory. We were a little crazy back then.
 
Mainframes often had text formatting in hardware to boost COBOL performance. Other mainframe languages didn't use the text formatting hardware so were not as efficient when creating reports.
 
I have learned COBOL because I think it is fun to know different languages, and COBOL definitely is different. As I understand it, COBOL was the result of the thinking of Grace Hopper: some people prefer to work with symbols (and for them we have FORTRAN, ALGOL, C, and a whole lot more), some people prefer to work with natural language (and for them we have COBOL). And I must say, working with COBOL had taught me I am more a symbols-person. I really prefer the C-family.

But I am also an accountant, and I try to teach colleagues a bit about programming and such, and I do see why COBOL is the better choice for some of my colleagues (doing no programming at all is the better choice for even more of them).

Besides that, COBOL definitely has its strong points. It really is focussed on business processes, has the right tools, does "simple" math easily, fast and reliable. The way COBOL approaches data in memory, in files, between modules, is both simple to understand and very robust. Not too fancy, but very usable for business applications.

I don't believe COBOL disappeared because it was outdated for its primary use, but because the pool of programmers began to dry up.
 
whartung said:
...
The real curiosity I have is why it was usurped by BASIC. In the mini world, BASIC was king. BASIC was everywhere.
Click to expand...
The COBOL compiler was quite complex, on order to process the language. BASIC was more interactive, and micros definitely didn't have the power/memory to support COBOL well. There were COBOL compilers for micros, but they were huge and slow (and took shortcuts with parsing). BASIC lacked the natural language, but was easier for developing programs on the fly. COBOL and FORTRAN are still being used today, but in more specialized areas. Modern compilers and interpreters can use a lot more resources and thus have become much more powerful, evening the playing field. Now, it's more of a programmer's choice which one to use.
 
m_thompson said:
Mainframes often had text formatting in hardware to boost COBOL performance. Other mainframe languages didn't use the text formatting hardware so were not as efficient when creating reports.
Click to expand...
I wonder if this is another urban legend. At CDC, we beat out IBM on COBOL by a long shot on a contract using word-addressed hardware with no special character handling. Your basic very fast RISC machine.

As to why COBOL, I urge you to study the language in detail, paying particular attention to its immediate predecessors, Flow-Matic and COMTRAN. It should then become obvious why COBOL was a good choice for business, particularly in light of other languages of the time.

Many aspects of COBOL were adopted by other languages, particularly in the area of data structures.
 
I converted some COBOL code to work in a GUI + SQL environment. It was a breeze. COBOL is close to the ideal of self documented code.

Business BASICs gained much of COBOL's database abilities while taking advantage of all the graduates with BASIC knowledge. That took a large share of potential COBOL installs in the late 70s and 80s. Much the same principle applies to educational BASICs gaining turtle graphics and preventing LOGO from moving to the mainstream.

Modern COBOLs can take advantage of all the newer hardware design concepts and even accept relational backends for datasets that would be inconvenient in traditional COBOL. The problem is that refactoring and rewriting in COBOL isn't much faster than rewriting in a language known by a good contractor.
 
Abmvk said:
I don't believe COBOL disappeared because it was outdated for its primary use, but because the pool of programmers began to dry up.
Click to expand...

What planet do you live on where COBOL disappeared?

To the original question: COBOL in this context is way more than the language; it's a compute ecosystem. And that ecosystem is designed around assimilating vast amounts of data, applying (usually many, many) business rules to transform it, delivering answer very quickly with extremely high availability guarantees. If COBOL environments had, say, the availability and response time of your average commerce web site, or didn't have facilities like CICS, we'd have turned off the last mainframe in the 90s.

N.B.: I work for a large bank. We do a lot of COBOL.
 
I've heard a lot of arguments over the decades about which programming language is "best" for a given purpose, and it really comes down to the programmer's preference. An experienced C programmer can write a business application in C faster than they could in COBOL, but that's not really the point. That fact that FORTRAN and COBOL are still in use today means that they have proven their place. The key to any high-level-language is libraries and extensibility, since most features are implemented in the runtime libraries. These days, you can get most DB API libraries for many languages, making the choice of language one of preference - driven by things like the amount of legacy code, available programmer skill, etc.

I like COBOL because it is so different from other computer languages. Although, I would probably never use it voluntarily. It was a real PITA on punch cards, though. Respect to COBOL programmers from that era, especially ones that didn't have an army of keypunch operators to do their re-writes.
 
How about COBOL with autocoder patches? COBOL has a few interesting features that are more difficult to implement on other languages. e.g. ADD CORRESPONDING or PERFORM para-1 THRU para-2 .

(I used to maintain a COBOL compiler in a past life. You need to have the mind of a lawyer figuring out if the standard allows a particular construct. The current 2023 standard runs to over 1200 pages)
 
Last edited:
whartung said:
The real curiosity I have is why it was usurped by BASIC. In the mini world, BASIC was king. BASIC was everywhere.
Click to expand...
Interactivity. For many people these days it's probably hard to imagine how huge a change this was, akin to moving from command lines to GUIs. (It's funny that it may well have been John McCarthy, of LISP fame, who did more than anyone to make BASIC successful by suggesting to Thomas Kurtz that he make it interactive.)

Abmvk said:
...some people prefer to work with symbols (and for them we have FORTRAN, ALGOL, C, and a whole lot more), some people prefer to work with natural language (and for them we have COBOL).
Click to expand...
I'm not sure how true that is. Who really prefers ADD 1 TO X GIVING Y to y = x + 1? Sure, there was once a time when people used a lot of "natural language" for mathematical activities, but since the 19th century we've expected six-year-olds to master what was once considered some fairly sophisticated mathematical notation.

Not to mention, the more I dig into COBOL, the more apparent it becomes that it's far from "plain English." The difference between ADD A, B, C TO D and ADD A, B, TO C GIVING D does not immediately jump out at one, I feel.

Chuck(G) said:
COBOL has a few interesting features that are more difficult to implement on other languages. e.g. ADD CORRESPONDING or PERFORM para-1 THRU para-2 .
Click to expand...
ADD CORRESPONDING appears to be a special case of what functional programmers do easily all the time by composing map, zip and similar functions. And standard functional programming techniques (probably all predating COBOL) easily give you all the different variants of PERFORM as well.
 
I think COBOL has it's place, and I don't diminish someone's worth because they prefer COBOL. It's not for me, but I have a different way of thinking than others. I think the intent of COBOL has merits. It's a different matter to decide if it meets those intentions, especially in the modern world compared to when it was originally conceived. I have heard plenty of people say they find/found COBOL easier than other languages, and that point of view has as much merit as any other.
 
I had a quick look at FLOW-MATIC, as Chuck suggested, and found some interesting ideas. Take, for example, the following sample program from Wikipedia:

Code: 
 (0)  INPUT INVENTORY FILE-A PRICE FILE-B ; OUTPUT PRICED-INV FILE-C UNPRICED-INV
     FILE-D ; HSP D .
 (1)  COMPARE PRODUCT-NO (A) WITH PRODUCT-NO (B) ; IF GREATER GO TO OPERATION 10 ;
     IF EQUAL GO TO OPERATION 5 ; OTHERWISE GO TO OPERATION 2 .
 (2)  TRANSFER A TO D .
 (3)  WRITE-ITEM D .
 (4)  JUMP TO OPERATION 8 .
 (5)  TRANSFER A TO C .
 (6)  MOVE UNIT-PRICE (B) TO UNIT-PRICE (C) .
 (7)  WRITE-ITEM C .
 (8)  READ-ITEM A ; IF END OF DATA GO TO OPERATION 14 .
 (9)  JUMP TO OPERATION 1 .
(10)  READ-ITEM B ; IF END OF DATA GO TO OPERATION 12 .
(11)  JUMP TO OPERATION 1 .
(12)  SET OPERATION 9 TO GO TO OPERATION 2 .
(13)  JUMP TO OPERATION 2 .
(14)  TEST PRODUCT-NO (B) AGAINST ; IF EQUAL GO TO OPERATION 16 ;
     OTHERWISE GO TO OPERATION 15 .
(15)  REWIND B .
(16)  CLOSE-OUT FILES C ; D .
(17)  STOP . (END)

Once you get over the flow control nightmare (particularly line 12), it's interesting to note what's not in this program: any significant work on parsing files or writing specific data formats. (There are some definitions of data formats not included in the example; I'm assuming that they're fairly simple and clear expressions of the format of the data.)

I think there may be something in that: anybody who's written programs to parse files without some moderately sophisticated helper tools knows what a pain it can be, particularly in lower-level languages such as assembly or even C. (Or many versions of BASIC, for that matter.) The ability to abstract this away was doubtless a big convenience to programmers dealing with files full of records.

Still, that control flow, and line 12....
 
My first job out of Uni (where I studied COBOL in 2nd Year) in the late 80s was as a trainee Unix Systems Programmer at a small company, supporting a few COBOL developers. Our application suite was for Building Cost/Materials estimation and was used by Australia's largest Project Home builders.
It was written in Ryan McFarland COBOL and ran on Unix SysVr2 & SysVr3 on Unisys 5000 series, Xenix on NEC APC IV's fitted with multi-terminal Stallion cards, and MSDOS single user boxes. Same compiled code for all platforms just a different runtime, I supported all of that.
Many a time I turned up at a customer site with a new build on a DC600 in hand. So for me I have nothing but excellent experiences with RM COBOL, it just worked. Wish I could say the same for the Java stuff I worked on later ("Write Once, Debug Everywhere").
 
Chuck(G) said:
What, you've never used assigned GOTO in FORTRAN?
Click to expand...
Assigned GOTO is relatively easy to understand, since in most cases you can simply read the local code. At worst I suppose it could use a global variable, but that's at least something you can print when debugging.

ALTER seems actually worse than COME FROM in that it not only automatically requires the entire program code for understanding, but it uses state not recorded anywhere: the only way to figure out what any ALTERed "goto" statement in the program does is to execute the entire program in your head.

I've played around with the continuation monad in Haskell and done some pretty nasty things with it, but I have literally never seen an idea this terrible outside of joke languages specifically designed to make understanding programs difficult. (And maybe not even there.)

How would anybody who cared even in the slightest about programs being readable, rather than confusing, introduce a feature like this into a language?
 
I was trained in COBOL in 1986, and worked on a batch-only system for the next few years, adding such things as Y2K compatibility. This was on a Unisys 2200 mainframe. Interesting language - I quite liked it. Confusing statements like the ones above were banned - everything had to be crystal clear. ALTER was obviously not allowed. Other projects at our company used COBOL for live transaction processing, with databases, but I was never involved with that. My online work was with the now totally-forgotten Unisys Mapper system (also known as BIS).
 
I forgot to add to my prior comment on COBOL. That is, don't diss COBOL. It or a 3GL/4GL descendant of it is quite likely running your bank account.
 
You must log in or register to reply here.
Back
Top