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.
Any good programmer can learn to program in COBOL given enough financial incentives.
Java, C, and Python are newer and more versatile than COBOL. I fail to see your point. Yeah, some are old, but COBOL is the oldest, so the sentence is still correct.
I worked for a company 20 years ago that had a Windows program written in VISUAL COBOL. It was terrible. It crashed all the time. When it worked, it was slow. We don't need more COBOL programs, but I hardly think that Python is the answer.
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.
Every year I see articles about how COBOL programmers are in high demand and companies are scrambling to hire them. But I learned COBOL and liked it and regularly keep my eye out for COBOL jobs. In the past 15 years I have seen a grand total one one COBOL placement within 1,000 miles. I call BS on the article, the local job boards are all for Java, C++, mobile languages and PHP. Not a COBOL position in sight.
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 mean, everyone knows that Ethernet uses the second and third pairs on an 8P8C jack, while Token Ring uses the first and second pairs. If they wanted to get it right they needed to just connect pairs 1 to 2, and 2 to 3, or if crossover, pairs 1 to 3, and 2 to 2...
Do not look into laser with remaining eye.
To some extent true.
I have messed around with Cobol a bit and even though it's a pretty stable solution when you work with it there are some stuff that it suffers from, and it's primarily that it has a hard time to interact with other systems once you get the data into a Cobol file. A file written with Cobol should only be read by Cobol and any data sent to a Cobol system must be written in fixed record format where every position is important. Negative numbers is a creature all of their own since some Cobol variants don't use a "-" sign, instead it tweaks the most significant byte of the number field to indicate a negative number - something that can cause other languages to barf.
As long as you are bowing to the god Cobol all is fine, as soon as you start talk about other solutions you get a blank stare from everyone working on the mainframe and they put you twenty steps down the ladder.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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. . . .
They are having trouble finding people AT THE REQUESTED PAY, they are looking to pay chump change of $30K
Multiply the pay you are asking by at least 6 and you will get a Cobol programmer within hours. If you use something outdated and rely on it, then be ready to pay extremely well to get someone that is an expert in it. Most anyone I know that is a Cobol guru wont even bother to apply for something under $150K a year.
So if they really wanted someone, they will increase the pay and benefits to entice a person to actually apply. Sadly this basic element of business is lost on todays morons that are "leaders" and "managers"
Do not look at laser with remaining good eye.
For the specialization and demand that the COBOL work offers (not to mention the familiarity with how to use the tooling and platforms that surround those systems!) the people should be asking for a minimum of $500/hour.
After all it's all large financial institutions that are brimming with money, and like the said literally billions of dollars flow through these things every day.
So if you are out there and you know COBOL I would double your rate today. If anyone asks just say that a number of people you knew who did COBOL contracting all just retired and so demand is through the roof.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
Well, true, either that OR, slightly more plausible - some new hot-shot CIO decided he wants to impress the board by upping the ROI/stock price by getting rid of a few hundred (or thousand) old, slow, smelly "programmers". So he did.
Just like HSBC did in 2012, lest we forget. New hot-shot CIO decided..and a new hot-shot l337 h4xx0r from the indian subcontinent decided... to upgrade MQ, of all things. Clearing the "Queue" in MQ makes the upgrade quicker... How many million people couldn't get to their "banking facilities" including, funnily enough, CASH, for a whole week, remind me again?
At which point old, slow, smelly "programmers" decided that 27 quid an hour wasn't going to cut it anymore, which it didn't. Not sure what happened to the hot-shot CIO though..
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.
People would be happy to learn COBOL in school if it did not suck the life out of people that touch it. And now that the only remaining jobs are maintenance ones, there is even less incentive.
I'm a good cook. I'm a fantastic eater. - Steven Brust
I started programming in COBOL in 1978. I spent a decade or so on IBM mainframes with COBOL and 370 assembler.
I never referred to anything as a COBOL file. There were many types of file and database structures on IBM mainframes. While many simple systems used fixed record formats it wasn't nearly always the case.
The FILE section of a COBOL program allowed for varying record sizes:
FD file-name
RECORD IS VARYING IN SIZE FROM small-size TO large-size DEPENDING ON size-variable.
WORKING-STORAGE SECTION.
77 size-variable PIC 9(5).
The language also allows for the redefinition of record layouts so the type of data and what is to be done with it can be determined at run-time.
Nobody's willing to pay experienced COBOL programmers all that much, even though they're demonstrably scarce.
Proud neuron in the Slashdot hivemind since 2002.
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.
Yeah. "All You Have To Do Is..."
Think about human languages. Translate "Out of Sight, out of Mind to a language like Chinese, where a literal conversion might be "no-see, no-think". Now take another automated translator and translate it back: Invisible Idiot.
Every language - computer or human - has its unique characteristics. There's an old saying, in fact that "Translators are traitors".
Case in point: COBOL didn't support variable-length strings. Most modern languages have little or no tolerance for fixed-length strings. IBM COBOL supported a hardware-level data type (COMPUTATIONAL-3) which can store penny fractions precisely. Most modern languages don't allow for that, and tend to use floating-point (COBOL COMPUTATIONAL-2). Which cannot store decimal values precisely. Fuzz the pennies on people's paychecks and see how long before the torches and pitchforks come out. It's one of 2 reasons why so many payroll and accounting systems are written in COBOL (with the other one being that there's not exactly a lot of leading-edge technology in basic financial systems).
Some of these things can be automatically dealt with - albeit with some inefficiency - some of the more subtle issues have to be dealt with more directly, just as we've never yet managed to construct truly generic software-writing systems and have to continue to use programmers instead of robots like we do with truck driving and day-trading.
I have, actually worked with/supported automated code translation projects using commercial translator products. Every one of them has required a time and manpower budget for the clean-up crew. You can get about 80% of the job done automatically (although the resulting code may look horrible to a native human programmer). But to get something actually working, the tools need human help.
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."
It's not the COBOL per se, but how it runs and integrates into the system.
The expertise comes in making files available to read and write output to.
In my post below, I noted that if you're running in MVS (old IBM iron), you need to know and be comfortable with JCL. Same thing for VMS.
That's where the grey hair comes in.
Mimetics Inc. Twitter
Think of Joel Spolsky hiring C++ programmers because they can reason deeply how code works and then he puts them in front of Visual Basic 6 to pound out his application because they don't have to fiddle with MFC to get the GUI part?
Well, what's wrong with that? I was a C++ programmer throughout my education and my first job as scientific programmer, and moved on to VB6 and then VB.Net. Double the pay for half the effort, what's not to like :) And in the end it's all just a Turing Machine anyway, we're just debating the syntactic sugar as long as we stick to imperative languages.
So nowadays I just use the tools that make it easiest to code and test a solution, not the tools that are generating the most work for everyone. For most applications in office automation there is zero reason to use C++. Heck, there is little reason to actually code anything when you look at office automation: a good logical model coupled with a business rule engine and a decent code generator could work up 99% of most applications without even breaking a sweat. You may not build SAP with it, but I bet you could give it a darn good run for its money when looking at specific modules - the joke that is the Student Lifecycle Module springs to mind immediately but I'm sure there are plenty of examples.
Therefore, by the (faulty) logic you're using, you're just a cow with a keyboard - osu-neko (2604)
You mean like how every modern database supports fixed point decimals and how every language has a type for them in their standard library (or some third party one)?