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.
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.
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.
Many organizations are rewriting COBOL apps in Java. I have heard this is IBM's recommended migration strategy.
There isn't a shortage of COBOL programmers. There is a shortage of COBOL programmers who will work for -less- pay than a medium-skilled web-developer.
Curiously enough, the skilled developers willing to work for the least pay tend to be older, and usually have the most experience working in COBOL.
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...
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.
Smells like bullshit. Must be creimer. It is. It is creimer. You forgot to mention COBOL. Troll harder next time. This will get you started:
My very first IT job in 2005 was a COBOL 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 COBOL NIC, and the project manager let them go without double checking their work.
Who said the sentence is incorrect? OP claimed to be amused by the sentence, not that it was wrong. If anything, the fact that it's true is what makes it amusing.
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
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.
I think being amused by their creation dates is pedantic.
What the author was trying to convey is that COBOL is a dead language, whereas Java, C, and Python are still widely used today for new applications. C might be nearly as old, but you don't need to round up 70 year olds to maintain it.
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?
I think being amused by their creation dates is pedantic.
What the author was trying to convey is that COBOL is a dead language,
It seems that billions of dollars would disagree.
If you think I voted for Trump because of this post, you're wrong. I voted for Dr. Jill Stein of the Green Party. Again.
They are just newer.
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.
No sig today...
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.
The building was five years old and wired for Ethernet. The financial institution had it wired for coaxial because of the coaxial switches in the network closet. I guess it was cheaper to roll out coaxial cabling than buying new switches for twisted pair cabling, as the Token Ring NICs could take either coaxial or twisted pair.
Smells like bullshit. Must be creimer. It is. It is creimer. You forgot to mention COBOL. Troll harder next time. This will get you started:
1) You're trolling me. 2) Did I forget to mention that the backend ran COBOL? No wonder you're hot and bothered. :P
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...
Thanks. That explains why some Twitter feeds are popular.
It must have been something you assimilated. . . .
By your definition of dead, no programming language is dead. There's always going to be someone, somewhere, still using it.
What makes it dead is that, beyond the odd outlier, people aren't actively building new things with it beyond maintaining it.
Plenty of places still have "dead" languages controlling everything. Go to an older steel mill sometime.
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!
Because COBOL can't run in the cloud?
COBOL is an efficient, practal tool to solve basic business application issues, it is primarily used on batch workloads and 'green screen' mainframe applications.
Rewriting applications that work flawlessly today into a new language, DB, and OS environment opens up what was a stable application to almost unlimited numbers of software issues.
The real migration path off custom COBOL applications is likely COTS software for business applications.
Ken
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. . . .
Ad hominem still being a logical fallacy employed by even intelligent people goes a long way towards explaining why those of us who refuse to register continue to do so. Arguing the point is always better than arguing the person.
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
It's good to see that you're using your full legal name here, "Frosty Piss", and not some sort of a pseudonym. Otherwise we'd have to think that you're trying to comment anonymously, like some sort of a coward.
It's a good strategy, and carries different and more-immediate risks. It's an attractive option for me because it allows factoring in new lessons-learned and it makes risks controllable: old COBOL code might not respond well to new requirements, and will eventually need to interface with new code--either new COBOL code or new code in some other language. You can't control those risks as well as you can control an elective rewrite, because the risk of new requirements is often surprising and under time-pressure, while an elective rewrite to remove technical debt is at your best pace unless one of those risks suddenly appears--in which case, you may decide the rewrite isn't ready, and that shoring up the existing mess a bit longer is less-risky.
An elective rewrite requires accepting those risks now and devoting the resources to the project immediately. That translates to "take an active step in causing disruptions and expenses that we don't need to", versus "take an inactive step in causing disruptions and expenses at a future time when we can't avoid it". This form of proposal requires reframing.
Reframing is a known method for improving decision making and reducing dorsolateral prefrontal cortex activation when making decisions. Generally, to make a difficult decision, the dorsolateral prefrontal cortex must activate on prefrontal reasoning and override the mid-brain response (the simple, automatic response) by force of expended energy. For a frame, "Do you want $5 today, or $10 in 6 weeks," you want $5 right now; it takes a lot of effort to resist the immediate reward. A null-framed form, "Do you want $5 today and $0 in 6 weeks, or $0 today and $10 in 6 weeks," produces a decision to wait for the $10 in nearly an additional 40% of the respondent pool. Essentially, the prefrontal cortex sees these proposals differently, and the midbrain has a reaction to both explicit conditions rather than a lack of response to the implied null conditions--and obviously finds getting $0 at any time offensive versus the alternate, so is somewhat less-focused on time as a factor.
So do you want to take controlled, manageable risks now and pay an expense to avoid uncontrolled, time-pressured risks in the future; or do you want to do nothing now and face uncontrolled, time-pressured risks at various points in the future when implementing a long-term solution to avoid more such risks suddenly cropping up afterwards will not be immediately viable?
An event which will occur at a random, probabilistic period and incur some penalty (call it $1,000,000) is less-desirable than an event which will occur at a random, probabilistic period and incur some smaller penalty (call it $100,000). The cost to replace these events--to mitigate future risks--can be high (e.g. $20,000,000); yet those future risks may be more variable ($10,000-$100,000,000, mean $1,000,000) versus the alternative ($15,000-$250,000, mean $100,000). Frequency may also be a factor, wherein a new system may already have the flexibility for many upcoming new requirements, and any changes may bring with them opportunity to cover additional requirements without gold-plating (e.g. it has to handle PNG images, and you used a library that handles 47 types of graphics formats--when it has to handle TIFF embedded in EPS, it already does that, and nobody went out of their way to spend additional time making that happen). Making the system ready for commodity environments means we can build test environments and more-readily detect defects before production changes, as well, without expending millions of dollars supporting said environments.
It's not a simple problem. It requires a reframe to present it as a complex but important consideration, rather than a scary hobby to keep someone busy. After that, you're ready to sit down and analyze the problem in its full scope to decide if you should proceed. I've had times when the answer was no, and that's usually when we're migrating to a new system soon an
Support my political activism on Patreon.
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
lol wut?
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.
On a more serious note, the cost to wire versus the cost for switches really depends on the number of drops, the relative port-capacities of switches to those cable counts, and any backbone (ie Fiber) costs needed.
Token Ring using the shared medium on each literal token ring segment allows for more nodes per segment than modern Ethernet with the mindset that two devices are a collision domain and thus one switchport per device is necessary. I haven't made a study of token ring so I don't really know how many nodes can be present on a given coaxial segment or even how token ring switches to divide-up segments work, but if they can get a dozen nodes on a ring then they can buy 1/12 the number of switches than they'd need for Ethernet, and if the nodes are idle a lot of the time then that's probably a fairly efficient arrangement.
As for Ethernet many manufacturers don't even offer full-width rackmount switches with less than 24 anymore, you have to buy workgroup switches and adapter kits to get down to 12 ports. Thing is, if I have only a handful of devices fed from a closet then I could have over half of that fairly expensive switch idle. In the case of Cisco products, that's a list-price $5000 switch if it's Gigabit with 10G uplink capability and PoE for L2/VLAN, no real L3, and if more than 24 are needed and I step up to 48 ports then your're talking $8000 list-price, whether you need 25 ports or all 48. To contrast that, when I have drops pulled in they're $150-$200 each depending on how many are being pulled and how difficult the building is to work with. I can't expect Token Ring to have the exact same cost per drop, but I would not be surprised if it's similar and if again, they don't need very many, it makes some degree of sense to stick with what they have versus paying thousands of dollars per closet for switches.
But with Token Ring essentially dead and having been in-decline for a long time now I probably would've went Ethernet anyway, especially depending on the quality of the Ethernet cabling present in the building.
Do not look into laser with remaining eye.
10/10 trolling, got a reply :)
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.
On a more serious note, the cost to wire versus the cost for switches really depends on the number of drops, the relative port-capacities of switches to those cable counts, and any backbone (ie Fiber) costs needed.
The conversion project was for 500+ workstations at that one branch office. Not sure how many branch offices were involved when the switchover to Ethernet took place at the NYC headquarters. I spent four hours waiting for NYC to turn on the switches from their end, four hours to do 250+ workstations by myself, and four hours to fix 250+ workstations that youngers messed up by not following directions. Finding a cab at 3:30AM was not fun either.
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.
'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,just take a look at most software/code that Americans have had much to do with..
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.
God bless. One of the most profound comments. It points out the sheer stupidity of the Reuters article.
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...
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."
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.
We really need a "-1: Total and utter fucking windbag" mod.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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.
'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?
Do you suppose there won't be new requirements to implement in the next 5 years?
When you say rewriting is a good strategy, do you have ANY idea what that entails?
It entails requirements gathering not just through stakeholder analysis, but through forensic programming. You need to ask engineers how the current systems work, ask managers and administrators what their technical tools allow them to do, piece together a conceptual view of the current system, and have programmers examine existing code--both large spans of barely-readable source code and decompiled and debugged binary blobs for which source has been lost--to get a list of required features, existing systems, and current integrations. Both the goal and the technical details of the current implementation need documentation.
You then need to structure the actual work. This first requires a strategy for incremental delivery, because you're going to need an agile methodology for this--there is far too much risk to write the new system in a vacuum, "test it," and just drop it all at once. You'll need to design ways to test the first pieces you can deliver without messing with production, and to unbolt the relevant parts of production and bolt in the new system. This repeats as you make further releases, replacing your hodgepodge of multi-era code with a unified code base.
You need back-out plans. You need to identify all risks, rank them, mitigate them, build contingencies, and ensure that anything you screw up can not only be undone, but identified. Messing up data accounting in invisible ways will tend to run for a long time before anyone notices the error. This means parallel deployment as a test environment--possibly for months--to validate your outputs on real-world workloads against the existing system before deploying the rewrite.
That's only some of the bare, early technical pieces. That doesn't include procurements, human resources, buy-in, communications plans for literally everything that impacts anyone, management of legal and regulatory concerns, and the like. This isn't a small project; it's a massive effort to remove decades of technical debt and reduce long-term operational risk. It's like the removal of a cancer that's wound its way dangerously through tissue, but is still not fatal and can be cut out without destroying the body: the longer it grows, the harder it's going to be to remove, and the more likely it is to lead to sudden vital organ failure. Banks and insurers are functionally-immortal and don't simply have to outlive their barely-viable systems, like a human who might make 90 or so and die of heart failure before the prostate cancer even starts making them ill; they can actually keep running forever, and die when the system fails.
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.
I've seen data-crunching mainframes in insurance companies running modern code. Not C#.NET, Java, and Python; they've got JCL and Rexx to chew through massive data sets and run huge reports. They use mainframes because the software on the mainframe and the I/O hardware does in twenty minutes the job a $300,000 bank of servers can't do in literally three weeks. They still use software written this century, and they've left off software written back when mainframes were "The Future". That software doesn't look like anything today's Web developers are familiar with--no PHP, no C#, no MongoDB-
Support my political activism on Patreon.
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.
Rewriting the code in another language is a costly endeavor, especially since the existing COBOL is being used in mission-critical environments. Introducing a port in a completely different language throws away 30 years or more of bug fixes that have gone toward making the existing systems extremely robust. The replacement software needs to be bulletproof before deployment, and the costs of creating software that solid can be downright absurd.
COBOL programming knowledge is going to be a very profitable niche for some time to come, especially if you have solid experience in other suitable languages if and when those systems are rewritten. I've considered learning it myself.
Good grief you're verbose.
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?
I never said anything remotely similar to there will be no new requirements. I was merely pointing out that there have been MANY changes already, and the stuff is still working. You, on the other hand want to spread the FUD that 'there may be changes that the COBOL may not respond well to'. Well, can you guarantee that whatever rewrite you do WILL respond well to these as-yet unknown changes? No, you can not. Therefore, what you are suggesting is that organizations spend tons of money and time, and incur enormous risk, to wind up with a system that will not necessarily be any better than what is already there,
I have no idea why you are babbling about SCADA systems and Oracle systems in an article about large financial institutions and COBOL, which are almost exclusively the realm of mainframes and CICS.
Of course the mainframe systems have to trust the data that is fed to them. Do you have some magical new system/language where that is no longer the case? If not, how is rewriting the COBOL code going to actually improve the situation?
lol
"The ability to delude yourself may be an important survival tool" - Jane Wagner -
Java is the new COBOL.
In the cloud.
Do you really want bank and government information being processed on some other guy's computer?
I'm not sure how well you've thought this through.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
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?
Modern COBOL compilers all support external languages, primarily that means C. So that is where you start; you write the new functions in C, and slowly replace everything. And yes, compilers can understand binary data.
If you think about the way that COBOL represents data, it is pretty obvious that all other languages that you would integrate with would be able to easily support it.
The reason that "chewing gum and tinfoil" systems don't randomly fail is that computers are non-deterministic. So instead of failing randomly for you to "hear about it," it fails whenever a programmer touches anything to make a change, and you don't hear about it because it is just some person crying in a cubicle on Friday night and why don't you give them some privacy? These are important systems that have a lot of old-school QA in place, so they're not going to fail very often even when poorly written. If you do enough QA, poor software quality mostly becomes an upgrade-cost issue.
You don't hear of security breeches involving these systems because these systems they don't like to tell you what is running on what computer and you'll only read in the news that such-and-such institution had some sort of breech and what the fallout was. They won't give you technical details. Only nonprofits and open source groups would tell you which system failed and in what way when there is a breech. Even an ISP hosting service only tells customers about breeches where they have to do some sort of technical mitigation. If you're not mitigating anything, you probably weren't even told. None of these COBOL apps have a public-facing interface, they're all behind the scenes. They're not the sort of thing that security researches can isolate and test and find bugs in, these are real running bank systems it would be illegal to try to hack them. So white-hat research doesn't get done on these unless it is internal, and that will remain secret. If somebody actually hacks one of these it is to steal money and they don't publish a teardown review on youtube.
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!
Risk isn't about guarantees; it's about control. Can you guarantee you won't die riding a motorcycle at normal speeds while wearing a helmet and body armor? No? Then why not just take side streets at 100+mph in a t-shirt and shorts, barefoot?
Support my political activism on Patreon.
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
Wow, talk about missing the point.
Of course you can't make guarantees, but what you CAN do is quantify both the COSTS and the BENEFITS of doing something. Something with a low cost/benefit ratio is probably worth doing. Something with a high ratio is not. In your motorcycle example, we can look at history to make a determination: protected riders fare far better than unprotected riders, so the benefit is great. The cost is not absurd, so wearing protection makes sense.
So we can also apply this analysis to this problem. One the one hand, we have the current systems. What is their track record of dealing with change?
Went from running on 24, to 31, to 64 bit addressing hardware
Went from data stored on punch cards and tapes to online DASD
Went from standalone systems, to networked with SNA, to networked with TCP/IP
Went from green-screen UI only available to bank employees to mobile apps available to all customers
Went from all batch-processing to mostly on-line
Went from account information only being available via a mailed monthly statement to being available 24 hours a day, updated in real-time
Etc, etc
Now, what is the supposed 'risk' with these systems? The pure FUD that 'there may be a change they won't be able to deal with'. Such as what, exactly?
On the other hand, we have the 'new and improved' systems. Exactly what is THEIR track record? Exactly WHAT change are the existing systems going to be unable to cope with, but the new systems will be able to cope with? Any examples at all?
It seems that the 'benefits' portion of the equation is sadly lacking (except for the FUD factor, of course)
Then there is the COST portion of the equation. The track record here is not good. There have been many public and spectacular failures doing what you suggest, all at enormous cost.
So what we see is a gigantic cost, and a benefit of 'maybe this' and 'maybe that'. When your cost portion is that large, your benefit portion better be larger, as in as close to a guarantee as you can get. You have not provided anything even close to that.
It's not just COBOL, though, it's all the other proprietary stuff IBM puts into its mainframes. I can get, for free, any language in halfway widespread use that I can practice with. Do you still need to know JCL and CICS and all the other alphabet soup things? Those you can't get for free.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
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.
When you say rewriting is a good strategy, do you have ANY idea what that entails?
Or just look at the results. Rip-and-replace projects have a failure rate that makes greenfield development look good.
That's why the sales keep rollin' in. We had $206M in FY16 revenue from COBOL Development and Mainframe Solutions, which is basically all the COBOL stuff plus the mainframe environment (CICS, IMS, JES) emulation. That kind of money adds up.
Why don't they automatically translate them to something more modern then run them in the cloud?
That COBOL source can be compiled to CLR IL or JVM bytecode, if you want "something more modern". Such a translator is already available; it's called a "compiler".
And as native or managed code, there's nothing to stop you "run[ning] in the cloud". Why would you think there was?
Perhaps not many organizations do it because there's no reason to do so.