PeopleSoft, one of the world’s largest ERP systems, still uses COBOL. I’ve had to debug it from time to time. But I’m not retired and not volunteering to help New Jersey.
When I worked for JCPenney, one of programmer’s license tag was SOC7.
Has anyone seen any actual specs on what NJ needs done? Is it just scaling to support 362k new unemployment claims?
95% of ATMs use COBOL
Coronavirus pandemic signals need for COBOL computer programmers | Mashable
Doesn’t sound that “legacy” (actual legacy systems notwithstanding!) to me, according to that link. I suppose it is “decades old”, unlike those new-fangled programming languages like C.
Since 73.5% of all statistics are made up on the spot I’d like to see more evidence that 95% of ATM swipes are powered by COBOL. I assume that a lot of financial software includes some old COBOL components that a lot of banking transactions pass through, but I will be astounded to find out COBOL was used to control a machine.
Yeah, no way in hell the ATM machines and network is running a single line of COBOL code. I can imagine a batching background process that runs on some bank mainframe that processes logged transactions related to some financial system that collects bank transaction fees and updates balance sheets, etc… but nothing customer facing.
The 95% statistic appears to be from a Reuters synopsis, in turn based on several other sources…not very technically informative
This sounds like some reporter misunderstood the fact that the back-end mainframe at almost any bank is likely running COBOL, but not the ATM itself. My understanding is that most ATMs run Windows with a Microsoft-developed set of specific APIs for POS controllers and ATMs called XFS (eXtensions for Financial Services). The programming language itself can be almost anything but I believe is often C or C++.
I do know for a fact that many banks run Windows on their teller terminals as well as on the terminals used by financial advisors, etc. The terminals themselves are basically ordinary PCs. The architecture there is often a “thin client” version of client/server, meaning that the terminal does little more than run a browser that accesses the bank’s back end through a secure intranet. Gone are the days when banks were married to IBM and most such terminals ran OS/2 over token-ring LANs and talked to the back end via SNA. Now it tends to be Windows, Ethernet, and TCP/IP.
It really seems like a “figures don’t lie, but liars figure” statistic. I don’t doubt that there are some old batch processes in banks running COBOL code (probably ACH transactions), and that most ATM transactions result in some effect on those processes, meaning technically “95% of ATM transactions involve COBOL”, but to cite it that way is meant to make one think that COBOL has a special importance to ATMs, a technology that most people are familiar with, which makes it seem a lot more relevant than it is.
After all, if the whole reason this thread exists is that COBOL is not enough of an ongoing concern to maintain a healthy enough population of developers that governments don’t have to grovel when some COBOL needs updating.
Most places will buy a software system from an outside vendor for things like accounting, inventory, payroll, etc. But more than a few places still insist on writing that stuff in house even though it’s not cheaper and it’s much harder.