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.
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.
I am amused by this statement, particularly seeing C on that list (developed around 1970, some 47 years ago) and Java because, well, Java. Who wrote this tripe?
If you want news from today, you have to come back tomorrow.
It's just another computer language, probably significantly less complicated than the languages that are around today. Should be able to write a translator to go back and forth between COBOL and Python pretty easily.
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.
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.
Thankfully our first daughter is an expert in programming languages. She and the first grand-daughter will fix this.
#Trump2020 #MAGA
My very first IT job in 2005 was an Token Ring to Ethernet conversion at a financial institution branch office. I made an extra four hours in OT because the uncertified youngsters couldn't follow direction, plugged the Ethernet cable into the Token Ring NIC, and the project manager let them go without double checking their work.
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.
Where are the SJW to tell us we should use Ada the feminist language named after a woman who was oppressed by the patriarchy?
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.
"You will get no course credit for COBOL, but you might want to take the class so you can get a job between semesters"
Few of us did (and I wasn't one of them), but those that did always had jobs come summer while a lot of the rest of us didn't.
And everyone says it's impossible for programmers to find jobs after 40...
The only thing necessary for evil to triumph is for it to be pitted against a slightly greater evil
it's Y2K all over again!
Why not use a program from the 50s and 60s? Don 't you want to make America great again?
They are just newer.
This reminds me of a funny email from a "head-hunter" a few years back, it read something like:
Looking for expert knowledge in:
COBOL,
S/360/OS/360,
VAX/VMS
Excellent pay in the region of, wait for it, 30k.
I replied with: Good luck!
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.
8% of the worlds computers still use XP, and they rely on javascript made for old versions of of IE. 50 Years from now there will be still XP boxes hanging around, and legacy javascript will outlast its HTML5 decendents. Meanwhile todays babies will graduate college after the Y2K38 deadline.
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
I have been looking for COBOL work for a while now. I don't see that many ads. And when I submit my resume I don't even get a call. So that means the isn't much of a demand and the supply must be much higher than the demand.
I've been using COBOL since I learned it in the 1990s. Now, I work 3-5 hours a day maintaining software that various companies just can't seem to bring themselves to replace.
I've been going up $50/hr every year for the last 5 years and nobody has balked yet.
Sounds like HR just copy and pasted the original job posting :-)
A lot of public safety and gov't code is written in COBOL, too.
When MicroFocus came out with their Object Cobol like 15+ years ago, I remember watching the change sink in.
Some of the orgs we worked for slowly rewrote their code and broke it up into chunks which made rewriting it in C/C++/etc easier.
But there's still lots of it out there.
"Truth is what works" -- William James "It works!!" -- o-dark-AM comment
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
If you think that's how headhunters get paid I'll be more than happy to find a few jobs for you.
I worked for a software company who's flagship application, which was medical related, was written entirely in Logo. Apparently, early on someone slapped together some prototyping to show management. Management being management proceeded to dictate that the entire application actually be written in Logo. I could not believe it, yet there it was.
Brought to you by Carl's Junior.
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.
It's a "fake word" such that spelling is mostly moot. Anyhow, here's a better description of the concept.
Table-ized A.I.
My college offered 4 semesters of COBOL. It was the worst experience of my time there, and one of the biggest reasons why I dropped out. Fuck COBOL. Sure there's the whole "if it ain't broke, don't fix it" mentality, but I mean, a screen door "ain't broke" but it's also not the best idea to fit your front door with. A Speedo "ain't broke" but it's also not best for winterwear... Time for the dinosaurs to upgrade. The money spent now would be cheaper than the ever-increasing maintenance fees over time.
Article is complete nonsense by someone who doesn't know what they're talking about. COBOL is only one part of a huge, convoluted, legacy IBM stack. NO ONE WANTS COBOL PROGRAMMERS. Knowing COBOL is only a fraction of the picture. These corporations need experienced CICS programmers who know DB2, IMS, and VSAM to support legacy code. COBOL is the glue language. The real expertise is knowing how to code CICS transactions using back-end things like DB2 or VSAM. You would need to learn deep niche skills to grok all that. People spend careers learning that stuff. Would take years to be even a little productive. It's a whole world all by itself. (Hint: many people DID spend their careers learning this stuff deeply, and corporations purged those employees.)
Can't think of car analogy. Math analogy - knowing COBOL is a lot like knowing Algebra - you're going to have to learn a little bit more to work on differential manifolds.
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.
Nope, the issue in finding COBOL developers is finding developers willing to work for that little in what appears to be a dead end job and skills with limited marketability.
You want developers, you have to pay the price.
Not enough developers, you pay to train them and pay them very well to stay.
I'd like to begin by adding that an experienced programmer (let's say somebody with over a decade of experience) should be able to pick up any language. If you have been exclusively using one programming language for your entire career including college, then you must be one in a million. Most programmers that I encounter have picked up dozens of languages and syntaxes over the years. When I received my first royalty check for programming in 1987, I was programming a Commodore 64 in BASIC with as little machine language as possible. In high school followed by college I was exposed to the likes of Pascal, FORTRAN, C, Perl, C++, Java, and the standard UNIX things (Bourne shell, regular expressions, sed, and awk) before I took my first full time job out of school. I think my experience is typical. If you need to learn COBOL for your job, you should have no trouble picking it up. Having to learn a new language or a new programming environment should be no obstacle for an experienced programmer.
More to the point, my first job out of school was working with options traders on a trading system. They supplied the algorithms and I supplied the code. In the end the company folded, because it was too hard to compete against the big guys with their deep pockets. But one bank we integrated with had for the time an amazingly large list of libraries that their library depended upon (kind of like GNOME and KDE and a lot of other things today). One of them was -lcobol. Quite simply a part of their software buried deep in some library was written in COBOL. I don't know how old the code was, but this was the early 2000's so I doubt it was new code.
Correct me if I'm wrong here, but I think this is the most likely scenario that a modern day programmer is likely to run into with COBOL. You're probably going to be working with a bank, and you will be using COBOL without having to worry about it. The library probably works fine, but the institution itself may occasionally have to delve into the library to add code or fix bugs. It's doubtful to me that people working in small or medium-sized organizations would be exposed to any real COBOL.
These institutions screwed loads of us after Y2K so I'm highly amused to see them panicking. They'd have to offer me vast sums of money to go anywhere near them now.
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.
Lords of Kobol hear our prayer, Guide us to the promised language for modern banking software.
The majority of companies that have been in business for more than 40 years still have COBOL on there mainframes. No one would have used anything else on a mainstream until the last ten years or so.
if it works, don't fix it.
Any guest worker system is indistinguishable from indentured servitude.
BCD math, I have yet to find any other language with as bullet proof implementation of BCD math
There are too many systems in banks that aren't documented and no one bothered to keep the source code. There are databases that contain ascii, ebcdic and binary packed decimal. I replaced a program once that I thought I knew what it was doing only to discover that because it was looking at every customers data it was creating a file that had a 1 bit flag for every customer that met some unspecified criteria. 6 weeks later another department complained that they were getting the exact same report everyday. Lesson learned. If you don't have the source code don't mess with the programs and even if you do you would have to reverse engineer every possible thing the program did. COBOL will be around until the last bank fails.
I'm dead and I carry a do not resuscitate in case of cobol emergency card!
GnuCobol supports multilanguage integration, GUIs, GNOME, Internet access, etc.
I don't know COBOL, but I do like this joke (which has been floating around much longer than this Reddit post): https://www.reddit.com/r/Progr...
People working on COBOL aren't 'cowboys'. They're (metaphorically, like the cowboy thing) guys with suits and briefcases who might be briefly exuberant by getting a martini dirty style and hoping nobody notices this outrageous whimsy.
Yeah, I know, there's a company named that. Go look at the employee pics.
That will $10k a minute plus expenses, and im taking a helicopter to the private jet. Make sure its full of whores and coke.
As someone that has to deal with legacy systems all the time this made me chuckle a little bit.
Oft times these systems are neglected for decades in favor of the flavor of the day technology, which typically fizzles and dies. While these systems plod along doing the job, picking up more than a few quirks from having the business rules change every other year and constantly re-designing a system that was meant to do one thing many decades ago. Yet never actually replace because it is not only too expensive to do so, but almost inconceivable due to the above mentioned fact that no one really knows how it does what it does anymore.
I've seen my share of really weird design choices where I was like "They probably did this crazy thing to get around that crazy bit" sort of logic.
"COBOL is so easy to read and debug that even without training, I could just follow the flow of the program . . ."
So, then, why do you need 70-something Dude out of retirement (not that I begrudge 10-somethin Dude making some coin on this job)? A reasonably skilled C++ programmer, as you point out, should simply be able to learn enough COBOL to do this work? 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?
Is the problem that a C++ programmer will be bitchin' and moanin' the whole time, "COBOL sucks" that you cannot hire him for this work. That maintaining a mission-critical but legacy COBOL program is beneath a C++ person? What if they, like, paid enough coin -- would C++ dude keep those negative vibes to themselves to finish the project?
Let us not forget that COBOL was designed to be readable by both IT types and business folks. I suspect it is still around not only because of the much derided legacy effect but because it was good at its job. Sorry, I have dug through object oriented code and other stylistic metaphors -- trying to determine why it doesn't work or is a terrible runtime pig. There is something brutally honest about COBOL that has stood the test of time. There is nothing attractive about discarding something because it was developed last year so is 'old'... does it suit the purpose? That having been said, I have written 20 Cobol programs in my life... and a Cobol compiler. They all worked correctly the first time... beats the heck out of anything I ever wrote in C or various assemblers. Since it all boils down to the same underlying instruction set we should recognize this is a fashion statement as opposed to a suitability for intended purpose.
I am not buying this. Anything in COBOL is readily and easily done in C.
And C excels at UIs? Huh? Are you telling me that writing, say, UIs for Gnome (or low-level Windows API) is well-thought-out?
OK, OK, maybe these C-based simulations of object-oriented programming paradigms to handle UIs are better than the stuff sandwich of C++ with either Qt+ or MFC? But, seriously?
It's not as much COBOL that you need to know as being fluent in CICS.
Damn you, now I am going to have nightmares about my college days. IBM, you suck.
ExxonMobil also uses COBOL for their backend payment system. Built in the 1970's, the system is antiquated but is still in use due to the complexity of the code. Exxon has spent a small fortune on private investigators to try to locate the original developer, to no avail. Teams of COBOL programmers have not been able to successfully update the software, as the system crashes when core parts of the software are altered.
That is why debit machines at the Esso gas stations here in Canada are brutally slow compared to just about everywhere else.
I know this because I previously worked as an IT security analyst for Exxon.
150 a year?
I get paid more than that and I get to work in Python, Ruby, Java... modern Linux. I wrote COBOL over 15 years ago -- albeit briefly. I might not be _good_ enough to parachute in, but I'd be willing to consider it.
Quite frankly -- my terms for working in COBOL are:
- I'm starving, homeless, addicted to drugs and alcohol and desperate
- You offer me a contract in which you pay me enough to retire -- including programmer appropriate golden parachute if you think we don't work out before the end of the contract.
I'm not committing resume suicide just because some bank has an IT problem.
Honestly, I think we'd be talking a salary approaching half a million with benefits -- or an hourly rate approaching punitive in the 400-600 range, with an understanding that I will be taking vacations and don't care about terms less than a year.
Yes -- I'm not "worth" that, but the point where I do COBOL for three years I'm going to demand that the employer cover my lost opportunity cost and them some -- and I do make that much for my employer in the domains I already know well.
I can work at any startup in the world now. What career is the bank offering in their byzantine infrastructure?
lol
"The ability to delude yourself may be an important survival tool" - Jane Wagner -
So these people have been making trillions of dollars while racking up technical debt the whole time? I'm shocked I tell you, SHOCKED.
The real question isn't why they haven't updated their systems or what they are going to do about it, but how in the world are they going to monetize technical debt swaps? I believe they'll figure it out.
USA! USA! USA!
I work for a bank and I do COBOL programming. Where is my money?
They are lucky it's only COBOL I work at a university and we still rely on shit that's written in ADA
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
funny my alma mater cant afford CS doctorates for profs so they have a CIS dept which REQUIRES COBOL so why are they so hard to find-lots of big business use COBOL systems
COBOL **is** going away because it is expensive and limiting. It is so because, as it is always implemented, it runs on a leased mainframe. Those things are niche technology with a limited and shrinking customer base, so the mainframe vendors are squeezing their few customers for all they can.
Getting off COBOL and the mainframe means greater OPTIONS for the customer.
As a prominent example, Customs and Border Protection is actively transitioning to be completely off mainframe technology.