Some have said that Java and other languages have libraries that can do fixed point math calculations. Yes, that is true. Java also does all it's fixed point math via library calls, which are much slower than native opcode support. And while it is fine for millions of transactions or hundreds of millions, when you are doing 2 billion or more transactions per second, like what happens in our financial systems, these external libraries just are not fast enough.
The dilemma with migrating COBOL is not that you are migrating from one language to another, but that you are migrating from one paradigm to another. The edges of Java or python on Linux have a different shape than the edges of COBOL on a mainframe. In some cases COBOL may have allowed the application to extend past what modern languages can support. For those cases COBOL running on a modern mainframe will actually be the cheaper, more performant and more accurate solution.
Also, COBOL works on machines that can hotswap any piece of hardware, and degrade gracefully if a processor dies. Reliability is everything when working with billions of dollars. Those machines also support ridiculously large I/O speeds; if you can't handle a day's worth of transactions in real time, you're out of business.
Plus, how would you even update these kind of systems? They are running trillions of transactions per day. They are using very complex code. Take the insurance industry, for example. They have 50 states, each with different legal requirements for insurance, that change all the time, and by all the time, I mean daily, not yearly. So you have 40 or 50 years of code base, and most of it commented out or maybe just not called as a function anymore but still exists. So if you write brand new code, and you have a Fortune 100 insurance company that sends out billions of dollars in claims and investments daily, pays out life insurance, pays out money for accidents, workers comp, homeowners insurance, umbrella insurance, etc, and it is working great right now, if you are the CEO, are you going to convert your working system over to Java or c or whatever?
And, there is just no way to test any system that replaces current COBOL programs, let alone the entire system, with all the different kinds of computers, technologies, etc, because it is not just the COBOL. It's the entire system. Just no way. Nobody knows what’s hooked up to what in these server rooms. It would take Indiana Jones with a torch to explore the damn things without setting off the booby traps.
And, actually, I read about one insurance company that looked into it, and hired IBM to do a feasibility study and if it was feasible, that they should do it. So IBM did the study, and despite the literally hundreds of millions of dollars they would clear to convert, they just said "F-ck it" and walked away. Who wants to take on that kind of liability if it doesn't work? Who wants to risk their company's reputation on something like that? Where all of a sudden, 85-year-old women are not getting their monthly annuity check and you have tens of thousands of them being kicked out of their homes because they are not getting their monthly annuity to pay their mortgage. What a nightmare.
Rewriting all the COBOL code in another language, just to have a snazzier language, is super costly, extremely risky, and zero benefits. Using another programming language, just for the sake of using the other programming language is a complete waste of time and effort. Stockholders, CEOs, managers, hate big projects...
They should toss it to the Rust community, they'll happily rewrite it in Rust, might not even need to pay them as long as you allow them to always tell everyone they are Rewriting it in Rust.
Anecdotal data point: I worked, as a consultant, with a team of COBOL programmers that had been sent to some kind of "Java in 21 days" course. The system they were in the process of writing when I came on board used the "float" type to store money.
There was a point at which one of the programmers said he ignored the tests on amounts that were failing in reproducible ways because he thought they were wrong.
To this day I don't know the full cost of replacing all the uses of float with BigDecimal, but I'm glad one of my fellow consultants had a math and finance background and was able to sort it out.
Why did the COBOL folks use float and not know about the problems with IEEE-754 floating point?[1]
Because they had been using COBOL, which, because it was purpose-built for business and accounting has fixed-point arithmetic, handles money naturally.
Yes but if you've spent your career working in a programming language that just does the Right Thing (per business/accounting rules), and you're thrown into a project with a language you don't know and need to do money math, it's not unreasonable to expect, until told otherwise, that 0.1 + 0.2 = 0.3.
The COBOL-turned-Java programmers I worked with may not have been the best (nor is Java all that), but the fact that COBOL does money the way we intuitively expect "out of the box" is why it remains in wide use. What other language has a built-in Money type that handles error accumulation and rounding the way accountants expect?
11 comments
[ 2.8 ms ] story [ 40.1 ms ] thread"The delays caused a 4.4 percentage point relative decline in total card consumption in COBOL states relative to non-COBOL states."
I'm not an expert, so I might be wrong on the details.
The deal is that COBOL has native fixed point math. Floating point just doesn't work. So, .1 just not exist at all in floating point. See: https://www.exploringbinary.com/why-0-point-1-does-not-exist...
Some have said that Java and other languages have libraries that can do fixed point math calculations. Yes, that is true. Java also does all it's fixed point math via library calls, which are much slower than native opcode support. And while it is fine for millions of transactions or hundreds of millions, when you are doing 2 billion or more transactions per second, like what happens in our financial systems, these external libraries just are not fast enough.
The dilemma with migrating COBOL is not that you are migrating from one language to another, but that you are migrating from one paradigm to another. The edges of Java or python on Linux have a different shape than the edges of COBOL on a mainframe. In some cases COBOL may have allowed the application to extend past what modern languages can support. For those cases COBOL running on a modern mainframe will actually be the cheaper, more performant and more accurate solution.
Also, COBOL works on machines that can hotswap any piece of hardware, and degrade gracefully if a processor dies. Reliability is everything when working with billions of dollars. Those machines also support ridiculously large I/O speeds; if you can't handle a day's worth of transactions in real time, you're out of business.
Plus, how would you even update these kind of systems? They are running trillions of transactions per day. They are using very complex code. Take the insurance industry, for example. They have 50 states, each with different legal requirements for insurance, that change all the time, and by all the time, I mean daily, not yearly. So you have 40 or 50 years of code base, and most of it commented out or maybe just not called as a function anymore but still exists. So if you write brand new code, and you have a Fortune 100 insurance company that sends out billions of dollars in claims and investments daily, pays out life insurance, pays out money for accidents, workers comp, homeowners insurance, umbrella insurance, etc, and it is working great right now, if you are the CEO, are you going to convert your working system over to Java or c or whatever?
And, there is just no way to test any system that replaces current COBOL programs, let alone the entire system, with all the different kinds of computers, technologies, etc, because it is not just the COBOL. It's the entire system. Just no way. Nobody knows what’s hooked up to what in these server rooms. It would take Indiana Jones with a torch to explore the damn things without setting off the booby traps.
And, actually, I read about one insurance company that looked into it, and hired IBM to do a feasibility study and if it was feasible, that they should do it. So IBM did the study, and despite the literally hundreds of millions of dollars they would clear to convert, they just said "F-ck it" and walked away. Who wants to take on that kind of liability if it doesn't work? Who wants to risk their company's reputation on something like that? Where all of a sudden, 85-year-old women are not getting their monthly annuity check and you have tens of thousands of them being kicked out of their homes because they are not getting their monthly annuity to pay their mortgage. What a nightmare.
Rewriting all the COBOL code in another language, just to have a snazzier language, is super costly, extremely risky, and zero benefits. Using another programming language, just for the sake of using the other programming language is a complete waste of time and effort. Stockholders, CEOs, managers, hate big projects...
There was a point at which one of the programmers said he ignored the tests on amounts that were failing in reproducible ways because he thought they were wrong.
To this day I don't know the full cost of replacing all the uses of float with BigDecimal, but I'm glad one of my fellow consultants had a math and finance background and was able to sort it out.
Why did the COBOL folks use float and not know about the problems with IEEE-754 floating point?[1]
Because they had been using COBOL, which, because it was purpose-built for business and accounting has fixed-point arithmetic, handles money naturally.
1. https://0.30000000000000004.com/
The COBOL-turned-Java programmers I worked with may not have been the best (nor is Java all that), but the fact that COBOL does money the way we intuitively expect "out of the box" is why it remains in wide use. What other language has a built-in Money type that handles error accumulation and rounding the way accountants expect?