Can anyone else see the problem with that question? People who don’t know about COBOL, talking about COBOL, people who don’t know about mainframes, talking about mainframes.
Let’s divide the "business" more appropriately.
The smaller the company, the less relevant the language, operating system and hardware become.
As we progress to bigger and bigger companies, choices become more important.
In the biggest companies, with a huge amount of things to do, financial transactions, recording huge and varied volume of shares, this kind of thing, with precision and speed: there you will find the existing systems in Mainframes, from IBM, with the programs within these systems running primarily on COBOL. With higher or lower level of "interoperability" with other "things" (other non-mainframe systems, web services, external databases, whatever they may be).
Why is COBOL so fast? Why the attention to this?
Due to the type of language that COBOL is. Fields of fixed length. Arithmetic decimals. Developed many years before the existence of modern theory on programming languages, there is little to protect the programmer. An alphanumeric can be treated as a number, not in the sense that an interpreted language can do, but by consideration by the programmer.
Obviously a more complete description of the language, even without comparisons, would fill at least one book.
Add to this, the IBM mainframe, with fixed or known length records (no record delimiters) and decimal machine instructions available.
Once again, at least one more book.
Add to this the accumulated experience of many years of massive systems.
Add to that... I could go on...
01 BRANCH-TOTAL COMP-3 PIC S9(9)V99.
01 ACCOUNT-TOTAL COMP-3 PIC S9(9)V99.
...
ADD ACCOUNT-TOTAL TO BRANCH-TOTAL
This ADD can (depending on the build options) generate a machine instruction. A machine instruction. Get it? One. No rounding problem. 100% decimal accuracy. On a CPU with a clock speed that anyone could wish for.
Replace a system that is full of this, in a combination of hardware/OS that can run for years without the need for a re-start (IPL), without constant security improvements, and that will run unchanged (even without a re-compilation), in 20-50 years of time, is not a trivial task.
And if anyone faces that task, you better make it right.
Remember, you can’t depend only on the hardware getting faster, because at the same time the business demands more, so the excess capacity/power never really exists (or at least not for long).
COBOL was developed in a partnership between seven major computer manufacturers and the US government (including the military) to provide a standard language on different types of hardware, specifically for business programming.
There were no other languages at that time that functioned this way for commercial purposes. (Each manufacturer had programming systems specific to their often different machine lines, even between their own machines)
Mainframe ownership and operation costs today refer to the amount of processing power involved. The processing capacity is required for the huge amount of transactional processing done.
IBM has development plans for COBOL for the next 50 years (see https://www.youtube.com/watch?v=JLMqkuou2-s). This obviously means that they have development plans for mainframe computers for the same period.
Migrating from Mainframe to other hardware for "back end" processing has no limits, but the replacement system has to be: as accurate as it is; as reliable as it is; no longer costs to maintain; stable for long periods of time ("backward compatibility") - The IBM System/360 architecture, which recently celebrated its 50th anniversary, is still the basis for the current z/Architechture for IBM mainframes. The application programs written 50 years ago still have an exceptionally good chance of working today. It is routine for systems written in the 1970s to still be running today.
A common approach has been to implement new systems on new hardware with new languages, and run existing mainframe systems alongside, looking for opportunities to reduce the mainframe workload as it grows. For these, the Time Trial has not yet been completed.
RPG and its variants is another IBM "long life" language, but it has always been aimed at smaller systems (Mini-computers).
Mainframes (and the systems that run) are still important? Look at IBM’s financial reports. Important sums are still being spent on new hardware and new hardware is still being constantly developed, at a considerable cost. From that, draw the conclusions yourself.
For more information on mainframes, IBM has made all manuals available to the public, and has published a large number of redbooks on various mainframe subjects. For those interested in more research, but without knowledge of Mainframes, this is a good starting point: http://www.redbooks.ibm.com/abstracts/sg246366.html
Apologies for Google Translate
Can anyone see the problem with the Question? People who don’t know about COBOL, Talking about COBOL, people who don’t know about Mainframes, Talking about Mainframes.
Let’s split the "business" up into Something more appropriate.
The smaller a business, the Less Relevant the language, Operating system and hardware become.
As we Progress through Larger and Larger Businesses, the Choices become more Important.
At the very largest of Businesses, with Massive Amounts of Stuff to do, financial transactions, Recording enormous volume and Variety of stock, that type of Thing, accurately and Rapidly: there you’ll find existing systems on Mainframes, from IBM, with the Programs Within those systems being mainly COBOL. With a Greater or Lesser amount of "Interoperability" between other "Things" (other non-Mainframe systems, web services, External Databases, whatever).
Why is COBOL so fast? Why the Attention to that?
Because of the type of language COBOL is. Fixed-length Fields. Decimal arithmatic. Developed Many years before the Existence of Modern Theory on Programming Languages, there is little to Protect the Programmer. An alphanumeric can be treated as a number, not in the sense that an Interpreted language Might do, but by deliberation on the part of the Programmer.
Because there is Lots of Stuff to do, and to do it Within time to Meet the business needs, it has to be done fast.
Obviously a Fuller Description of the language, Let alone comparisons, would Fill at least a book.
Add to that, the IBM Mainframe, with Fixed- or known-length Records (no record delimeters) and decimal machine Instructions available.
Again, at least Another book.
Add to that the cumulative Experience of Many years of Massive systems.
Add to that... I could go on...
01 BRANCH-TOTAL COMP-3 PIC S9(9)V99.
01 ACCOUNT-TOTAL COMP-3 PIC S9(9)V99.
...
ADD ACCOUNT-TOTAL TO BRANCH-TOTAL
That ADD can (Depending on Compile options) generate one machine Instruction. One machine Instruction. Go it? One. No rounding problems at all. 100% decimal Accuracy. On a CPU with a clock speed anyone would Wish for.
To replace a system which is full of that, on a hardware/OS Combination which can run for years without requiring a re-start (IPL), without Constant "security" upgrades, and which will run unchanged (without Even a re-compile) in 20-50 years time, is a non-trivial task.
If that task is Taken on, you’d Better get it right.
Remember, you can’t just rely on hardware Getting Faster, because at the same time the business wants more, so the excess Capacity/power Never really exists (or not for long).
Original, recovered from a "recently closed tab" (Thanks Firefox) and including some minor edits. Please Feel free to Edit google’s Attempt at your language:
COBOL was developed in Partnership between the seven large computer Manufacturers and the US Government (including the Military) to provide a standard language Across Different hardware specifically for business Programming.
There Were no other Languages at the time which would operated in this way (each Manufacturer had specific Programming systems for their Own ranges of machines, often Different Even between their Own ranges) for business purposes.
Costs of Owning and Operating Mainframes Today relate to the amount of Processing power involved. Processing power is required for the Massive amount of Transactional Processing carried out.
IBM has Development plans for COBOL for the next 50 years (see https://www.youtube.com/watch?v=JLMqkuou2-s). This obviously Means they have Development plans for Mainframe Computers for the same period.
Migrating from Mainframe to other hardware for the "back end" Processing has no Limits, but the Replacement system has to be: as Accurate: as Reliable; not more Expensive to run; stable for the Coming Many years ("Backwards compatable") - IBM’s System/360 Architechture, which recently celebrated its 50th Birthday, is the Basis for Today’s z/Architechture for IBM Mainframes. Application Programs Written 50 years ago, still stand an exceptionally good chance of Working Today. It is routine for systems Written in the 1970s to still be Able to run Today.
A common approach has been to implement new systems on new hardware with new Languages, and run the existing Mainframe systems alongside, Looking for Opportunities to reduce the Mainframe Workload as they arise. For These, The Test of Time has not been completed yet.
RPG, and its variants, is Another long-lived IBM language, but that was Always aimed at smaller (Mini-computer) systems.
Are Mainframes (and the systems they run) still Important? Look at IBM’s financial Reports. Considerable Amounts of money are still being Spent on new hardware, and new hardware is still being Constantly developed, at considerable cost. Draw what conclusions you like from that.
For more information on Mainframes, IBM has made all their manuals publicly available, and have Published a large number of Redbooks on Various Mainframe subjects. For those interested in more research, but with no Mainframe background, this one is a good Starting-point: http://www.redbooks.ibm.com/abstracts/sg246366.html
I have absolutely nothing useful to contribute, but whenever I see something related to COBOL I think of a phrase by Oswaldo Santo André: "Who says that Cobol died, watch out! For he suffers the great risk of having his death certificate and the Invoice of his coffin made by a Cobol system"
– Bruno Augusto
I believe it is because it is costly to upgrade the entire legacy system, not only in cash, but in efforts, resources, time and etc.
– Math
There is another saying that ensures the survival of systems made in COBOL: do not try to fix what is not broken.
– Oralista de Sistemas
This question does not meet the standards of this site and should be terminated.
– Bill Woodger
Interesting discussion, but not pertinent to the philosophy of the site. And look who worked years with COBOL.
– Motta
I see no reason to close, I left open because the question is direct, well-structured and nay has nothing to do with opinion, but with unique and objective answers (The only exception could be the second doubt).
– Andre Figueiredo
@Andréfigueiredo Editei.
– Laerte
First to answer the question should be answered if the fact is true, COBOL still dominates the corporate market ? What metric ?
– Motta
http://redmonk.com/sogrady/2014/01/22/language-rankings-1-14/ http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://www.computerworld.com/slideshow/detail/98085#slide9
– Motta
Where COBOL is used in Mainframes, COBOL dominates in Mainframes. Where COBOL is not used in Mainframes, it obviously does not dominate. There are no surveys that are not able to reflect this reality is any use to measure anything to do with COBOL. "I’m going to do a survey of all the elements of planet Earth by sampling the atmosphere" Do not be surprised if something, what does not enter the atmosphere is lost.
– Bill Woodger
I was negative on responses based on "achism," as @Billwoodger said:
Pessoas que não sabem sobre COBOL, falando sobre COBOL; pessoas que não sabem sobre Mainframes, falando sobre Mainframes.
. . . . Historical memory: my first stage was with COBOL, when I decided to abandon Computer Science and do Social Communication.O– brasofilo
COBOL IS EVERYWHERE, EVERY DAYI
– user22054