Slashdot Mirror
Major Banks and Parts of Federal Gov't Still Rely On COBOL, Now Scrambling To Find IT 'Cowboys' To Keep Things Afloat (reuters.com)
From a report on Reuters: Bill Hinshaw is not a typical 75-year-old. He divides his time between his family -- he has 32 grandchildren and great-grandchildren -- and helping U.S. companies avert crippling computer meltdowns. Hinshaw, who got into programming in the 1960s when computers took up entire rooms and programmers used punch cards, is a member of a dwindling community of IT veterans who specialize in a vintage programming language called COBOL. The Common Business-Oriented Language was developed nearly 60 years ago and has been gradually replaced by newer, more versatile languages such as Java, C and Python. Although few universities still offer COBOL courses, the language remains crucial to businesses and institutions around the world. In the United States, the financial sector, major corporations and parts of the federal government still largely rely on it because it underpins powerful systems that were built in the 70s or 80s and never fully replaced. And here lies the problem: if something goes wrong, few people know how to fix it. The stakes are especially high for the financial industry, where an estimated $3 trillion in daily commerce flows through COBOL systems. The language underpins deposit accounts, check-clearing services, card networks, ATMs, mortgage servicing, loan ledgers and other services. The industry's aggressive push into digital banking makes it even more important to solve the COBOL dilemma. Mobile apps and other new tools are written in modern languages that need to work seamlessly with old underlying systems. That is where Hinshaw and fellow COBOL specialists come in. A few years ago, the north Texas resident planned to shutter his IT firm and retire after decades of working with financial and public institutions, but calls from former clients just kept coming.
I hope all these COBOL programmers are smart enough to charge outrageous rates. Minimum $250/hr.
They've got the banks over a barrel, any time the situation is reversed the banks don't hesitate to screw us.
From what I've seen, the issue in finding developers for these codebases isn't in the language knowledge (i.e. COBOL), it's in the knowledge of the poorly-documented legacy software. Sure, you can get a developer to learn COBOL fairly easily, but when the software is full of dead ends, spaghetti code, and unknown business logic and workflow logic, their knowledge of COBOL won't help. Instead you need to hire someone who knows the system, and was probably complicit in creating this mess, to do anything. Either that or bite the bullet and start a huge replacement project that costs several magnitudes more than exorbitant hourly rates.
A sentence can be technically correct yet still reveal the writer to be an idiot... sometimes in subtle fashion that other idiots wouldn't necessarily pick up on...
COBOL has been around long enough to be a victim of featuritus. I has a lot of built-in operations and short-cuts that are great if you know them, but could trip up a newbie.
But the hard part of a typical COBOL job is probably learning your way around many thousands of lines of existing programs. I've always found writing code simpler than reading code written by somebody else, especially if it's poorly structured, documented, commented, etc.
The language and syntax the business logic is written in is secondary to that issue. Readable code can be written in any language, but so can crazy pasta.
Table-ized A.I.
One of the nice things about f77 and i presume cobol is that memory is allocated in a fixed way at compile time. so no mallocs and no deallocs and thus no null pointers. string buffer sizes are known. and relatively speaking, its harder to find cases where typos are not also syntax errors. for exapmle typing = instead of ==.
now for many things this memory issue is the pits which is why we like those other laguages. it makes object oriented styles impossible though for a fixed maximum number of objects you can fake it. but for a lot of things its all you need. and the block memory structures of multi dimensional arrays make data contiguous in memory and enable very efficient parallel optimizations. so there are advantages to giving up features.
if you are wanting very reliable code its not a crazy choice,
Some drink at the fountain of knowledge. Others just gargle.
I supported several apps based on Microfocus COBOL and so-called Visual COBOL. No significant problems with either platform, the apps worked as well as thne programmers did, or more correctly, bugs happened. One was rock solid, the other had predictable issues with every major release that were resolved without much delay.
Stereotyping COBOL is inevitably just age discrimination. It's functional, as the history and current situation proves. It's a language, competent programmers that have progress from C to C++ to Java will figure it out if they see profit in doing so. I work with an old-school COBOL programmer who has no patience with the young whippersnappers who whine about every problem a legacy platform presents. There is so little interest around here to abandon the core transaction systems that claims that COBOL is 'obsolete' fall on deaf ears. They train new maintainers here. What a concept, training your team! Gah!
deleting the extra space after periods so i can stay relevant, yeah.
Easy to learn, fairly easy to read. However, the Lords of Cobol are masters at programming in a way that most people today can't think. it is a quite literal programming language.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
The COBOL programmers at my place are actually using it to develop new functionality that's keeping up with the financial world and actually pushing the leading edge. They've done nightly program releases since literally decades before the term "agile" was a thing. The notion that COBOL is just a legacy hold on that is in maintenance mode everywhere is also somewhat of a misconception. That's probably the case in some locations where it's providing a core business function and the rest of the infrastructure has evolved around it to patch the functions that support whatever the modern requirements are but there are plenty of people using it to create new function as well.
Why don't they automatically translate them to something more modern then run them in the cloud?
Maintaining these systems is just throwing good money away. Money that we all end up paying via our bank charges.
Translate debugged, working, proven code into something else? Not really a good strategy for production code. I also doubt that maintaining those systems is a problem or limiting expense. Modern hardware can run COBOL just fine. As TFS implies, the expense is in finding and hiring people trained in (or willing to learn) a language many don't see as useful and/or sexy -- mainly 'cause it's old. Newer / younger isn't always better or less expensive
It must have been something you assimilated. . . .
Correct. I've been a COBOL gun for hire for 15 years, mostly in finance, and the rubbish you have to get your head around sometimes is amazing. On the flip side I've seen some very clever things too.
Once I had to fix a nasty bug in a clearing system causing dropped transactions; took me a day of scrutinising thousands of lines to find the logic error.
Largely it is actually all being phased out though, contrary to this article. There were times I could have $3000/hr contracts, they're much less frequent these days.
Haha! IBM is making a 'killing supporting old systems'? IBM comes out with NEW mainframes about every two years. The current system (z13) is from all the way back in 2015. And you won't find 'better hardware' anywhere. Cheaper? Certainly. Better? No.