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.
Any good programmer can learn to program in COBOL given enough financial incentives.
$250/hr is an "outrageous rate" to charge a bank? What are you, 14??
Ever since I first joined /. there has been an article a year stating:
- Major organizations, banks, governments, etc. are still relying on COBOL.
- COBOL programmers are in great demand so dust off your old MVS skills (and maybe pull out those JCL manuals) and offer up your services, you're in demand!
What I really think is the big takeaway from all this is simply that the need for supporting for your old software is never going away - so think of a way of monetizing it.
Mimetics Inc. Twitter
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.
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.
Is there any programming language with "Visual" in the title that's worthwhile?
Do not look into laser with remaining eye.
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.
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.
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.
$250 per hour is a pretty normal rate for an experienced professional, hardly outrageous at all. When I worked for IBM Global Services, they billed me out at $300 per hour. Granted that IBM commands a premium due to their marketing channels, but I'm sure I could have gotten $200 per hour on my own and my expertise is far from as rare as deep COBOL experience. I'd expect people like the one mentioned in the article to cost more like $500 per hour, if they're actually aware of their own worth, and I wouldn't consider even that outrageous.
If I were in the position of those programmers, I would probably try to avoid quoting an hourly rate at all. Instead I'd do it all as piece-rate work, based on detailed specifications -- especially if I'm working on a system that I know, so I have a good idea of what sorts of obstacles I might run into. Then I'd try to set my price based on the value of the work to the business, rather than on the time it would take me to produce it. That could easily result in contracts that work out to many thousands of dollars per hour.
A friend who is a lawyer told me that the best piece of career advice he ever got from his father, also a lawyer, is "Take the money, son." He didn't mean to take money for unethical work, but just that one shouldn't balk at accepting high fees just because they seem too high. If the customer is willing to pay, take the money. That attitude should absolutely be applied to doing contract work for banks.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
COBOL is the Caterpillar D11 of data processing.
When you need to process millions of records reliably and constantly, a correctly constructed COBOL solution is robust, maintainable, and reliable.
COBOL doesn't and shouldn't give a shit about drop downs, java, PDFs and all that other bullshit. It's is doing the heavy lifting that C, Java (don't make me puke), and all these other supposedly superior languages can't do.
Eye Candy has nothing to do with making sure 50,000 employees get their checks every week or millions of SS recipients get their checks every month.
And the best thing, it's not rocket science...by design. A single semester of COBOL can get someone up to speed to the point where they can maintain everyday COBOL applications. When things get crazy, it's not the language that's the roadblock, it's just the normal analytical skills.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
'Eventually COBOL will need to interface with new code...' Eventually? Do you suppose these programs had support for EFT, ATMs, bank-by-phone, online banking, mobile apps, etc when they were written 50+ years ago? You're not going to scare them with 'Oooh - there could be a new requirement!'
When you say rewriting is a good strategy, do you have ANY idea what that entails? You are not just talking about a few COBOL modules here and there. You are talking about potentially changing the ENTIRE system. Your COBOL program is probably running under CICS. The hardware CICS and your program have been running on have been optimized for your workload. Your data is probably stored on ECKD DASDs. Your data is probably stored in packed decimal format, so it can be operated on with a single, optimized, machine instruction.
Now, you want to 'rewrite' it. OK, where do you start? If you just replace your one COBOL module with some other language, does your 'new' language natively support the data you are operating on? Does it support the types of datasets you are using? Does it do those things with the same performance characteristics as COBOL? Does it properly and efficiently interface with CICS?
Your last paragraph is laughable. These 'old' systems are 'chewing-gum-and-tinfoil' unreliable systems? Oh yeah? When have you heard of one of these systems failing? When have you heard of security breeches involving these systems? And before you incorrectly say 'airlines', I will point out that NONE of the recent airline outages involved the mainframe portion of the operation. It was the 'new, better' stuff that falied in every case.
It never occurred to them because they're not anywhere near as smart as you.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."