Why is COBOL still the preferred language in the business world?
As everyone knows COBOL is very used by financial institutions, where only the interface is made using current languages such as Java.
- the cost to maintain mainframes is great, but is the migration to a current language higher?
- is currently used a lot but in 20 years, it will still be advantageous to continue using mainframes and maintaining legacy systems COBOL?
- is there any limitation that makes this migration of COBOL not done? (Ex: data consistency)
- at the time that COBOL began to be popular in the business area, was there no other similar language or is it unique that remains alive?
7 answers
Can anyone else see the problem with this 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 larger and larger companies, choices become more important.
In the largest companies, with a huge amount of things to do, financial transactions, registering huge and varied volume of actions, this kind of thing, accurately and quickly: there you will find the existing systems in mainframes, from IBM, with the programs within these systems running mainly in COBOL. With greater or lesser level of" interoperability "with other" things " (other non-mainframe systems, web Services, external databases, whatever they are).
Why is COBOL so fast? By what attention to it?
Due to the type of language COBOL is. Fields of fixed length. Arithmetic decimals. Developed many years before the existence of modern theory about programming languages, there is little to protect the programmer. An alphanumeric can be treated as a number, and not in the sense that an interpreted language can do, but by weighting on the part of the programmer.
Obviously a more complete description of the language, even without comparisons, I'd fill out at least one book.
Add to this, the IBM Mainframe, with fixed records or of known length (no record delimiters) and available decimal machine instructions.
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 statement of machine. A machine instruction. Got it? A. No rounding problem at all. 100% decimal accuracy. On a CPU with a clock speed that anyone could wish for.
Replacing a system that is full of this, in a combination of hardware / OS that can work for years without the need for a RE-start (IPL), without constant security improvements, and that will run unchanged (even without a re-build), in 20-50 years of time, is not a task trivial.
And if someone faces this task, it is better to do it right.
Remember, you can't just depend on hardware getting faster, because at the same time the business demands more, so 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 U.S. government (including the military) to provide a standard language in different types of hardware, specifically for business programming.
There were no other languages at that time that worked in this way for commercial purposes. (each manufacturer had specific programming systems for their machine lines, often different, even between their own machines)
The cost of owning and operating Mainframes today refers to the amount of processing power involved. The processing capacity is required for the huge amount of transactional processing performed.
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 the Mainframe to another hardware for "back end" processing has no limits, but the replacement system has to be: as accurate how much; as reliable as; cost no more 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 next door, looking for opportunities to reduce the Mainframe workload as it grows. For these, the test of time has not yet been completed.
RPG and its variants is another" long-lived " IBM language, but one that has always been intended for smaller systems (Mini-computers).
Mainframes (and the systems that are they still important? Look at IBM's financial reports. Significant sums are still being spent on new hardware and new hardware is still constantly being developed, at considerable cost. From this, draw the conclusions yourself.
For more information on Mainframes, IBM has made all manuals publicly available, 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 the stock, and 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 in the 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. Arithmetic Decimal. 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 delimiters) 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 edict. Please feel free to edit Google's attempt at your language:
; COBOL was developed in partnership between the seven large computer manufacturers, and the U.S. 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 the Mainframe to other hardware on the back-end processing has no limits, but the replacement system has to be: the accurate: as has been; not more expensive to run; the 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 Mainframe computers. 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
A banking institution needs to process an immense amount of data daily, cannot afford the system to get "out of the air" from time to time, and needs a correct answer for complex calculations in a predetermined time. For this reason, migrating systems - mainly from one platform to another completely different one - is not something that can be done routinely, given its high cost and especially risk.
I don't know what modern versions of COBOL, but as far as I know there is an explicit advantage in using it in the sense that it is able to manipulate the database directly (at least the banks that were designed to interface with this language). Although SQL processing is relatively light in the most common uses, it is still a overhead that makes a difference if it is eliminated. Not every use of COBOL avoids SQL, of course, and I wouldn't know what percentage of current systems - if any - still use it this technique, but it is still known fact (believed?) that this platform offers performance beyond the usual in transactional systems.
As for maintaining mainframes, it is good to remember that the increasing virtualization of servers has allowed this platform to be brought into the era of cloud computing: not only is there constant maintenance to this environment, but it has also modernized to both support legacy applications, allow new applications in modern languages (not all, but some) and even improve the COBOL compilers to make these systems even more efficient.
Nowadays a professional who Masters COBOL is difficult to find, but on the other hand he is very well paid, so that there will always be a percentage of developers who will follow this direction. The same goes for Fortran - language still widely used in the scientific environment.
Finally, as for the last item, I can not tell you for sure, but a quick look at "timeline of programming languages" (Wikipedia, in English) I notice that every decade (including ours) several new languages appear, some become popular and others are forgotten. Certainly the languages of the time were more similar to each other than between them and the languages of today, but sufficiently distinct as, say, Java and Python. That is, I believe that it is the case that COBOL is "the only one who remains alive".
Has nothing to do with being preferred or not. What happens a lot is that, imagine your company that has a Baita sistemão that does a lot of things and that satisfies you and gives no problem. Never gave data inconsistency, it is quick to rescue and/or view the information you need.
An entrepreneur asks himself: What bitch am I going to change this system for? It is cheaper to buy / develop a new and with new technologies or pay an employee/outsourcer who can do any implementations "when" needed?
As much as I'm a programmer, I think this is the view of entrepreneurs.
The cost to maintain mainframes is great, but is the migration to a current language higher?
The cost to maintain mainframes is large, however, mainframes are known for 99.9999999% "nine nines" availability. As a customer of a bank, I like to have my money always accessible!
The cost of a migration to a current language depends on business to business and the return on investment of that migration. In addition, the risk of migrating a system may not compensate for this migration.
Currently it is very used but in 20 years, will it still be advantageous to continue using mainframes and maintaining legacy systems COBOL?
Of course yes! There are systems that have code working since 1980 and are still working today!
Is there any limitation that makes this COBOL migration not done? (Ex: data consistency)
In technical terms no. However, COBOL on the mainframe uses an encoding that most people do not know, which is EBCDIC. How is it a system that only dinosaurs know (yes, because dinosaurs still exist!), it takes many dinosaurs to migrate a cobol system!
At the time that COBOL began to be popular in the business area, was there no other similar language or is it unique that remains alive?
I think Fortran is the same height as COBOL, however, only the dinosaurs know COBOL!
COBOL, today, is one of the safest and fastest languages in the commercial environment. I'm not saying that C or JAVA are "fragile", but COBOL, because it does not have so much documentation and material available for consultation (not in the same way as other languages), has become a very interesting tool for those who aim for security. Contrary to what many think, COBOL is not "outdated" or "dead". Just like C, it undergoes constant changes. There is still an evolution in it, even if your syntax is old. Thus leaving, its development, in a way, slow. He did not stop in time. And surely migrating an entire system, especially banking, to another language, even when the current one is fulfilling its role, is a loss of money and a huge rework without big returns.
At the time COBOL began to be popular in business, was there no other similar language, or is it unique that remains "alive"?
He was created for this purpose, be a language of banks, trade, etc.
Some recent statistics to reinforce the use of COBOL and the mainframe environment in enterprises:
92 of the 100 largest banks in the world use cobol / mainframe; 23 of the world's 25 largest resellers use cobol / mainframe; All 10 safest companies in the world use cobol / mainframe; cobol / mainframe support 90% of all credit card transactions cobol / mainframe execute 30 billion transactions per day
Before we think about the ideal technology, we have to think like consultants, like entrepreneurs. Cost/benefit assessment in addition to information security dictate the rule on systems implementation in companies.
Another relevant point is that it does not matter the language if the solution is not successful, well applied.
Well let's go: Initially COBOL is not the preferred language in the business world, because it is an ancient language, it is widely used in banks and financial institutions. In addition to these segments, State-of-the-art infrastructure also uses a lot of Mainframe languages. Knowing: Due to the large volume of data processing, Cobol and other mainframe languages such as Natural, Adabas (the two from SoftwareAG), Cobol, Easytrieve among others have become extremely popular languages popular. Today it is believed that more than 70% of the existing codes in the world are still in some Mainframe language. In addition, the" difficulty "in hacking a Mainframe environment has also always been very great, giving a" q " of security to bank details. Another factor that makes Cobol and other languages still widely used is the aforementioned fact that there is still a lot of code in that language and rewriting those codes would be extremely expensive, and if it's working well, you have no reason to invest in rewriting. Today, through various tools, it is possible to integrate several languages with the Mainframe, making this language even more "immortal".