this post was submitted on 18 Dec 2024
193 points (99.5% liked)
retrocomputing
4215 readers
32 users here now
Discussions on vintage and retrocomputing
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
the reason transactions take so long is because of compliance. COBOL, CICS (the tramsaction manager) and mainframes themselves are constantly being updated and optimized because no flavor of the week in the last three decades has been able to handle the throughput needed by the companies that still use them. if anything in the tech stack at banks is slowing down your paycheck getting cashed, it's the small army of nodeJS servers whose entire codebase gets rewritten every six months because some exec thinks COBOL isn't sexy enough and we can get rid of it we say the word "agile" enough. the fortune 500 has been planning on being "off the mainframe in the next 3 years" since the 90s
Yes. COBOL instructions map nearly directly (something like 1:4) to machine language instructions on the mainframe chipsets it was built for. It strongly encourages stateless procedures with its design, and has some other benefits that align closely with the financial sector. You can drop down to assembly as a hot spot optimization if you really need to.
The industry could replace COBOL, but its replacement would wind up looking a lot like COBOL at the code structure level, or a slightly nicer language would have an intermediate transpile step into COBOL or something similar. Probably no performance gains. Perhaps some usability gains. Not enough to sell it as a rewrite.
Reality is its use will probably outlive us all.
In the meantime let's fire up some AS400 (yes I know, it's called IBM i or whatever now nobody cares)
My last company was selling IBMi's and writing the code for them. Customer's didn't like our GUI product. They wanted rock-solid, green screen menus.