09-08-2022, 10:36 PM
The reason Cobol is still around is (1) the huge investment in the care and feeding of existing applications; (2) the expense of converting to something else; and (3) the extreme dependence on existing applications.
Consider your typical Extremely Large Bank, N.A., any of the world's 50 largest, having anywhere from 100 billion to 1 trillion+ of liabilities (the money depositors put in their accounts) and assets (the money people owe the bank). Every single one of them operates their business using IBM z/System mainframes running z/OS, and CICS (transaction processor) possibly VM (a hypervisor). All or almost all of their operations use either programs wrtten by third parties or internally, and if that program has anything to do with managing customer accounts, it's written in Cobol.
I gave this example. That bank went to automation as it became available. When IBM released the S/360 in 1964, they bought or leased one, and started writing their own applications - in Cobol - to handle the bank's operations. Batch processing of checks and deposits, plus loan payments and generating payment coupona. Then as all the things that were developed came allong, the new features were either added as new modules or bolted on to the main programs.
So, banks got ATMs (circa 1969) and had to handle those. Meaning now the bank had to handle real-time balancing of customer accounts (lest some smart guy who has $200 go to every branch with an ATM - all 12 of them - and withdraw $100 each. Then banks invented continuous interest and the calculations had to be done. Then the other features ATMs offer including potentially paying your mortgage. Then came BankAmericard (Bank of America licensed it to other banks who gave it their own name). And its competitor Master Charge. Then cash advances from credit cards at the ATM. Then all of the following: telephone banking, ATM networks, branch banking (some US states did not allow branch banking), Internet banking; bill pay; direct deposit; funds transfer; wire transfer; home equity line of credit; interest on checking accounts.
But through all of this, today, there might still be code processing parts of the system thst was written in the 1960s and 1970s, that still runs today, unmodified (in some cases, the sourve code was misplaced or lost). That bank may have spent over $50 million over the years on the care and feeding of those programs and the hardware to run it, plus salaries of the progreammers that performed the magic incantations that allowed these expensive programs to do all that they do. These programs are literally what keeps that bank operating. They cannot fail. They cannot have errors. If something fails, it csn mean millions of dollars an hour in losses.
Now, with the stakes that high the bank is going to be very conservative with technology. The hundreds or thousands of programs that the bank uses to opeate are essentially bulletproof; thy've been using them (with changes) for longer than some of the programmers doing maintenance on them have been alive. Change is risk, and unless you show a huge payback, a big ROI they aren't going to be iterested.
IBM's CICS transaction processing system, which the bank's terminals are connected to (or PCs running 3270 emulation software) along with their ATM nachines, not only suooirts Cobol for applications, but also C (probably C++ too but I'm not sure). New things might be developed using C, but anything critical that currently exists is not going to be rewritten uaing it. There will probly be people 50 years from now working as programmers for these large banks that are maintaining Cobol programs written n the 1970s and '80s.
Consider your typical Extremely Large Bank, N.A., any of the world's 50 largest, having anywhere from 100 billion to 1 trillion+ of liabilities (the money depositors put in their accounts) and assets (the money people owe the bank). Every single one of them operates their business using IBM z/System mainframes running z/OS, and CICS (transaction processor) possibly VM (a hypervisor). All or almost all of their operations use either programs wrtten by third parties or internally, and if that program has anything to do with managing customer accounts, it's written in Cobol.
I gave this example. That bank went to automation as it became available. When IBM released the S/360 in 1964, they bought or leased one, and started writing their own applications - in Cobol - to handle the bank's operations. Batch processing of checks and deposits, plus loan payments and generating payment coupona. Then as all the things that were developed came allong, the new features were either added as new modules or bolted on to the main programs.
So, banks got ATMs (circa 1969) and had to handle those. Meaning now the bank had to handle real-time balancing of customer accounts (lest some smart guy who has $200 go to every branch with an ATM - all 12 of them - and withdraw $100 each. Then banks invented continuous interest and the calculations had to be done. Then the other features ATMs offer including potentially paying your mortgage. Then came BankAmericard (Bank of America licensed it to other banks who gave it their own name). And its competitor Master Charge. Then cash advances from credit cards at the ATM. Then all of the following: telephone banking, ATM networks, branch banking (some US states did not allow branch banking), Internet banking; bill pay; direct deposit; funds transfer; wire transfer; home equity line of credit; interest on checking accounts.
But through all of this, today, there might still be code processing parts of the system thst was written in the 1960s and 1970s, that still runs today, unmodified (in some cases, the sourve code was misplaced or lost). That bank may have spent over $50 million over the years on the care and feeding of those programs and the hardware to run it, plus salaries of the progreammers that performed the magic incantations that allowed these expensive programs to do all that they do. These programs are literally what keeps that bank operating. They cannot fail. They cannot have errors. If something fails, it csn mean millions of dollars an hour in losses.
Now, with the stakes that high the bank is going to be very conservative with technology. The hundreds or thousands of programs that the bank uses to opeate are essentially bulletproof; thy've been using them (with changes) for longer than some of the programmers doing maintenance on them have been alive. Change is risk, and unless you show a huge payback, a big ROI they aren't going to be iterested.
IBM's CICS transaction processing system, which the bank's terminals are connected to (or PCs running 3270 emulation software) along with their ATM nachines, not only suooirts Cobol for applications, but also C (probably C++ too but I'm not sure). New things might be developed using C, but anything critical that currently exists is not going to be rewritten uaing it. There will probly be people 50 years from now working as programmers for these large banks that are maintaining Cobol programs written n the 1970s and '80s.
While 1
Fix Bugs
report all bugs fixed
receive bug report
end while
Fix Bugs
report all bugs fixed
receive bug report
end while