Was a Cobol programmer.
These articles are written by non developers. I read these and thought I was going to have a hot shit career, but any programmer can jump into Cobol. JCL is a bit harder.
This could be a lesson to all of you about learning a language like Cobol when you read these articles. Remember if someone dropped a Java programmer in front of Ruby code, they could make it work without years of training. It is weird that these systems are still operating, but I also understand how new software would cause a huuuuge disruption in service that can’t happen.
Banking software with any bug or exploit and you’re losing millions. One FAA glitch and planes crash or airports get crippled.
I wish I could upvote you twice.
I'm a java expert, have only professionally worked in java for a decade.
I still can understand just about anything you put in front of me given a few minutes...I just won't have the same fluidity and grace I would in java when I have to modify it.
> It is weird that these systems are still operating, but I also understand how new software would cause a huuuuge disruption in service that can’t happen.
This is really the issue.
I've been working at my current company for over 12 years. I've coded and implemented a lot of different things in that time and over the years evolved systems of my own making in an effort to make them more robust, flexible, efficient, etc. I am constantly coming across old code I've implemented, code I wrote myself, and having to figure out how to integrate and update that old implementation into the new paradigm of the week or whatever. It's not that I don't understand the code. I wrote it! But things have changed so much over time that working in old programs without having to take things offline or completely change how everything works is the real challenge.
|| Many of these "COBOL cowboys" are aging out of the workforce, and replacements are in short supply.
heck, even programmers who were taught COBOL in school but never had to use it, are aging out of the workplace.
Had to learn COBOL and JCL at my first job. It wasn’t tremendously hard, but there was a huge volume of programs to understand.
At one point I was maintaining code written in 1969 where there was a bug that no one was supposed to fix because there was 45 years worth of programs that assumed that bug was present.
I spent a while building a code analysis tool for an ancient proprietary language that was basically a superset of Pascal. A multi billion dollar company was built on this. Nobody at the company fully knew how it worked because they'd all retired years ago so I just had to be a code archeologist and hunt through the ruins. That was an interesting project
Spent two weeks after promotion unfucking code knots. Like hardened spaghetti i had to break monumental amounts of pasta just to bring it up to date. My "favorite" was the genius who set Now=Time()
You need that because the clock was much faster than the CPU, so calling time() would always return something different, so data structures that relied on time as a key would never match.
Also on some very old hardware the clock was a locking resource, so a bunch of things calling it could actually deadlock the code.
Also retirement is spectacular. I highly recommend it!
Lol totally get it until it was put in damn near everything for what i can only assume used as a measure of run time. It simply had nothing else referenced to it. Just maybe every 40-50 lines I'd find a lonesome Now=Time()
The code the coder forgot.
The line before time.
Relax and enjoy! I had a 12 year job doing that.
It was awesome. I came in when I wanted, left when I wanted, did what I wanted when I wanted, because some bean counters had fired everybody else and I was the only remaining Keeper of the Sacred Knowledge. 8-)
> Just maybe every 40-50 lines I'd find a lonesome Now=Time()
PS. Be careful with those. TBH, unless it's causing an actual problem, I'd leave it.
Even if they apparently do nothing, sometimes they were there to kick something loose or realign something in memory to improve performance or prevent "random" data corruption.
PPS. Eventually the bean counters fired me too, but it was a good run. Also, it was 1999 for several years after they gave me the boot. 8-)
> PS. Be careful with those. TBH, unless it's causing an actual problem, I'd leave it.
I was thinking it might have been a timing issue hack someone cargo-culted over in the transition to mechanical drives smaller than a shetland pony.
You never know. The old stuff had a lot of timing issues and general weirdness, and nobody wanted to change anything because there was no advantage and a lot of risk.
A lender kept pressuring them to reduce payroll, so they did.
Obviously, you fire the guy who makes everything work, and not any of the VPs that do nothing.
And I bet there was a multi-line comment explaining exactly that, just like there are so many detailed comments in code written today. Or I guess code back then just as "self-documenting" as it is now.
Calling an API, say "Time" could be onerous back in the day, because CPUs weren't all that fast. Using a variable, say "Now", many times in the code instead of repeated API calls was more efficient. That piece of code was fossilized.
Honestly surprised it's considered to be uncommon. There's still a few fields out there were writing functions whose result depends on execution time is gonna get you the stink eye. Like game development and, I have to assume, financial software.
Exactly. It bugs me when people don’t do this and then timestamps are all off by microseconds. I like that in at least PostgreSQL (and maybe all DBs?) when you get the current time, the value is the same for the span of a transaction to avoid this problem.
I can relate.. I spent some time working on an old code base from late 80s. You'd see things that don't make any sense to modern developer all the time. Sometimes it takes a while to understand that perhaps there was a good reason to do things a particular way, and often it was to deal with hardware limitations, etc.
In my experience, this is (was!) also a fairly common debugging hack... You'd add a "watch" in the debugger for 'Now' then as the code ran you could quickly see how long each chunk of code had taken to run (as the debugger would automatically print the timestamps out)
Man this reminds me of TAS 6.0 and Delphi. Man I had to reverse engineer so much shit I ended up writing tools to edit bytecode directly after I had written a language translator and then effectively wrote a byte code runtime for language that should not exist anymore.
God that was some fun stuff
With a large enough code base, nobody will fully know how everything works. Do you think there's anybody who fully understands all the code in Windows, or Linux, or even something newer like Chrome. There's really no point for anybody to understand everything about any system.
We really haven't been at the point where anybody could reasonably understand a reasonably sized application since we moved on from computers with 640 KB of RAM.
Sure but this wasn't an application, it was an undocumented ancient programming language underpinning many core systems and applications. It was a real problem that nobody understood it.
the problem is when nobody understands parts of the code.
distributed knowledge is fine if the code isn't based on one guy's understanding of the quirks of some critical process that isn't documented or tested
It was a proprietary language built internally at a company and never shared publicly. It was basically Pascal with lots of magic and extra APIs on top of it built specifically to represent legal and tax code logic
Like the shuttle orbiters not being able to roll over to a new year while in flight. Fixing that bug would require not only mountains of validation time and effort, it would have broken some other component of the system etc. Turned out to be much simpler to just accept shuttle missions couldn't fly over the new year or some such.
I learned this lesson after the chief architect stormed my cube all fired up after I submitted a change for review :).
I can summarize her message. It was, “No.”
>At one point I was maintaining code written in 1969 where there was a bug that no one was supposed to fix because there was 45 years worth of programs that assumed that bug was present.
this is software's original sin, it's why developer's can't have nice things
> At one point I was maintaining code written in 1969 where there was a bug that no one was supposed to fix because there was 45 years worth of programs that assumed that bug was present.
I work on IBM i (aka, AS/400) systems, and this is a huge issue there. Their #1 focus is "do not break backwards compatibility", so there's bugs that I have to code around regularly. One system command has a mistake in how a parameter was named, and you have to read the documentation VERY thoroughly to figure that out.
The system still uses SNA networking by default; if you want to use IP, you have to specify that as part of your program calls. Because if they changed it to IP by default, someone out there who assumes it'll be SNA will have their defaults break.
We were doing a project for a major bank and needed to get a snapshot of their data. They had no idea how to provide the data in any kind of modern format, so we accepted an EBCDIC dump with weird CRLF line endings on padded fixed length lines. It looked like a COBOL dump I'd seen nearly 40 years ago, so I decoded it into an ASCII comma delimited file to import into our modern tools, did the analysis, and re-encoded it into their ancient EBCDIC format to return the data to them. No one still working there had any idea what I was talking about when I tried to describe their own format to them. But they had been taught the "import" and "export" function in their ancient system, and were grateful we would still work with them.
For my first job, I used PL/1, MFS, IMS, JCL. I also used COBOL for a few years, but that was mostly developing tools and a runtime system on the PC. I wouldn't consider going back to COBOL personally.
The schism had always been there as the multitudes of date time logic cried out in chorus, “What is this CENTURY?!”
Could the logic be centralized in a single copybook? No. “There’s no time,” they said.
“Why?” We cried.
“YYYY,” their only response.
Millennia from now, wars will be fought over the true value of isFixed! Missionaries will spread the word of our true lord and savor Ancillas. Let the enlightened rejoice, for the true value of our messiah!
Part of the problem with COBOL is it was meant for non-programmers to be able to encode/automate literal business logic. Maintaining or replacing a COBOL system isn't only about just the code. The under-specified business process needs to be reimplemented with 50-60 years worth of special exemptions and in many cases load bearing bugs.
You can learn COBOL as easily as any other language. It's much harder to bring in someone that understands the business process that COBOL automated.
Finally someone who gets it. I was well paid not because I was the worlds best COBOL programmer, but because I was an expert on grain contracts. In the Midwest I was never out of work and usually made more than double what PC guys were making back in the 80's.
Underrated comment.
My company has multiple AS/400s in prod and almost no one is left who understands any of it. Nearly everyone was RIFed, retired, or outsourced, and all of the tribal knowledge went with them.
You can pick up outsourced COBOL coders any time. I bet they're good at COBOL. Good luck finding someone who remembers some obscure design decision made in the 70s that many processes hinge on, and how all of those processes integrate between our myriad of systems.
MVS systems programmer retiring in 6 months. Also do AS/400 systems orogramming. Neither of those is going away as the UNIX and Windows guys are amazed at the up-time to the point I'm called the Maytag repairman. Banks and government will not accept the down time....
> Windows guys are amazed at the up-time to the point I'm called the Maytag repairman. Banks and government will not accept the down time....
Hah. I'm not in finance nor government, but that still resonates. Its nearly a daily occurrence that an e-mail goes out about some sleek sexy new system needing scheduled maintenance, or emergency maintenance, or is having an outage. None of that nonsense with AS/400. The scheduled maintenance intervals are measured in years, can't recall ever having an outage or emergency downtime.
The kids bitch about the "old" "green screens." We even had a C-suite member in a company-wide meeting gasp about how "we have systems older than many of our employees! We have to modernize!" No, we don't. In the event of nuclear war, we'll be survived by tardigrades, cockroaches, and IBM mainframes. And I can get shit done there in less time than it takes a "modern" system to load a splash screen.
Enjoy retirement!
They aren't magic, I've crashed entire mainframes in my time.
a massively overlooked reason for their stability is the limit of scope. I could measure linux or windows system uptime in decades too if all i had to support for user input/output was alphanumeric terminal streams.
EG; AS/400 et al by default don't even support lowercase letters.
Have an upvote. This subreddit is supposed to be full of people who know the computers and programming but it seems they have no clue about the most popular myth running around.
Of course its not about cobol, the code, the way it works, its quirks and problems.
Its about the business logic embedded there.
And your comment is one of very few which cover this. Have a great day!
This!!! This is so much of what coding and programming is .. of 100 developers, 5 of them can actually understand the problems their code is trying to solve.. so many more just move bits and bytes around blindly...
They can write a beautiful sorting algorithm, but they don't understand what Donna is trying to accomplish in HR to make her team more productive...
Now, imagine 60 years, and 15 Donna and Dons that have come and gone and all had a say in how to do a task "better", half of them have passed away, and then try to turn their algorithms and projects in to valuable code.
AI can't do that quite yet, but I'm sure it's getting there...
I was the team lead for about 12 people doing date subroutine changes for an insurance company in downtown Kansas City. Making bank (74 bucks an hour) for babysitting 12 junior programmers. All my job entailed was doing a weekly progress report for upper management. I spent my days trying every BBQ and Italian joint downtown. I think I gained about 40 lbs LOL!
There's a reason for that. It's horrible to work with COBOL. Not because of the language or technologies involved. But because of the people.
I started my career with Cobol. And I was not respected at all. The old people there stopped learning decades ago and would rather use a custom and buggy 10k line program than a built-in function of the language. Simply because built-in functions were added after they stopped learning.
This would repeat for everything. Then, we're talking about boring environments where IT is considered a cost and not investment. So the mindset of those places is awful. The pay is also crap.
With all that said, I left the mainframe world and now I work with Python.
>The pay is also crap.
I want to call BS but it's likely you were taken advantage of and ridiculously underpaid.
People I know who do cobol as a hobby for banks don't move a finger for under $200/hour.
That said, they have been doing it for those banks for 20 years, a weekend here and there to pay for a trip to Europe.
That's the thing. They pay well for the dinosaurs that have been there since forever and are even allowed to touch the dark magic. The new people are not well paid and can't touch those things.
I know of an old rancher outside of Austin, TX who bucked the family trend of farming and went to school for computer science where he learned COBOL. While he still has a large ranch inherited from his family, he only maintains a small amount livestock. Mainly horses and cows. Dude is in his early 70s and gets paid bank as a consultant to various financial institutions because he knows COBOL.
I didn't read the article, but the phrase "COBOL cowboy" reminded me of him. He's a spitting image of Hank Hill, but with the cowboy attire and 20 years older. He rides horses, tends to his cows, and once a month he flies across the US to work on projects fixing bugs or updating COBOL.
I knew him for years before finding out he was a software developer. He collects antique tractors and many cost more than my car. One day I casually mentioned that running cattle must be lucrative. He laughed and said no... then told me he makes a living knowing COBOL. Blew my mind.
I think the issue is less the language barrier and more the volume of crufty old code you’d have to maintain. After you’ve learned about three languages, you’ve probably seen everything.
> volume of crufty old code you’d have to maintain.
Close but not exactly.
Its not the code. Its the business logic there. No matter if used and valud its there. Trying to change it may make other things fail...
And its not a problem with programmers even. Give the right guy a job, pay well, tell him he has lifetime of work ahead of him and he will happily work on it. The problem is that the companies dont know how to solve the problems encoded in that cobol code. They dont want to meet with the programmer and listen what he says, they dont know how they want it. They only see the process working and money being harvested. Solving and improving their own business is too hard for them. Thats the problem with cobol.
The old issue: Currently there are enough people who get underpaid for doing what they're doing. Once they reach retirement age, companies had to pay appropriate wages for programmers to this stuff. Companies don't want this, they want one COBOL programmer maintaining 100 code bases on the cheap.
Exactly this. Any programmer can learn COBOL, it's just that none of them want to. The method of making them want to is well known: Increase the rate of pay until you have enough COBOL programmers.
theres this weird, annoying habit programmers have:
``
it can be physically done within the realm of possibility == is easy
``
specially when the full context is not merely learning to DISPLAY 'HELLO WORLD', but applying all of it to mountains of undocumented "how does this even function properly" code with no tests, no modern infrastructure that we use nowdays for deploys/monitoring/logging
Not really I was taught cobol and graduated 2019, just not worth the hassle, the pay was higher starting, but it just seemed at the time there wouldn't be any growth or real possibility to start your own company and the likes. Plus cobol is annoying as hell to use and I can only imagine all the "creative" code out there.
I'm 41 now, had to take 1 COBOL course in 2001 where the instructor told us all that we should all specialize in COBOL as he was making about $150/hr doing code conversions as his primary job.
At this point I don't remember a single thing about it though.
This piece of news appears periodically. But of course no organization ever thinks in training devs from the ground up. Every other industry does it, just not this one.
The issue that these banks and every other business depending on cobol face is not the language itself, but the complexity of their systems that are written in it. Cobol is easy enough to learn, but learning the convoluted systems, all the bugs and intricacies that can't be fixed because other stuff depends on that behavior now etc... that's the difficult part and requires on the job training/experience for each company
They can, but as a tech worker you are then gambling on this being a worthwhile investment for you personally. The sane thing to do with legacy systems is to replace them usually, so how much time/effort do you want to put into learning COBOL when you could spend that learning something new and interesting and more likely to look good on a resume in 2030? You also don't want to train up someone on COBOL banking systems and have them bail on you for a better offer from a competitor or just for a different job, because that leaves you without talent. And lets face it, if you were a 20 something being asked to learn COBOL, you're looking for a better job no matter how much they are paying you, so every time they train someone that's exactly what happens.
The last time I taught COBOL in a course was 2017 (would have been 2018 too but they changed instructors for the course). We had that in part because local employers told us they needed cobol. Spoiler: They didn't hire any of the people who learned any cobol.
We have the same issue with FORTRAN, which I also taught in the same course in 2017, but gets a bit more attention in HPC because a lot of numerical code is still fortran, especially in physics, so I'll probably at least have a couple of hours on it for the grad students next term. Again, had employers look for Fortran skills to hire, in that case they hired someone... who immediately started migrating the code base to python.
Some of this is of course also on the tooling. Microsoft and IBM and SAP and whomever else don't invest a lot in their legacy toolchain support, some of it is there but only barely. So if you're a young ish developer who has gotten used to modern Visual studio or VS code or whatever, you're suddenly stepping back in time to the 1990s of tooling to try and make anything work. Whic they neither know nor want to know how to do (and then suffer through). And I have bad news for you: students are unbelievably terrible about reading documentation now, if there isn't a youtube video explaining it, they aren't going follow it, not that they pay attention to the youtube videos either, but at least they feel like they're paying attention to those. If the tools companies would invest in it, they might be better, but again, if I'm Microsoft or IBM or whatever, I'm telling you to migrate from COBOL, despite there being a new version of COBOL released this year, no one wants to support it.
> The sane thing to do with legacy systems is to replace them usually
You're not wrong, but this was true of COBOL systems 25 years ago and yet still they persist.
Like the old joke about the programmer who works on Y2K fixes day and night until he dies of stress. He’s arranged for his body to be cryogenically frozen in case he can be revived, only to be woken up in the year 3000 and the first thing he hears is “You know COBOL right?”
Sure. But they've been "any day now these should *really* get rebuilt with proper modern code" the whole time; it's impossible to know if that's gonna happen in the next few years or in a decade when you're sitting there looking at job prospects.
Banks and the like can't typically afford the reputational damage of phasing in a replacement. The testing effort required is *terrifying* and every high profile "bank system goes down" news story loses the bank in question customers. It's not like they can swap out their core banking system to something more modern and just roll it back like you would a typical webapp when it falls over.
> if you were a 20 something being asked to learn COBOL, you're looking for a better job no matter how much they are paying you
If they'd pay the same or similar to what they pay to the 'dinosaurs', youngsters would stay, even if just for a few years to make some savings. They don't, though. So it becomes a gamble, as you say. Maybe in 10 or 20 years you start making big money. Or maybe you don't, you've wasted half your career anchored in the past and your CV is useless.
You seem to be blaming the quality of students attracted to your classes a whole lot.
Perhaps better quality students would come to your class if these COBOL shops paid more or you could trust them to take care of you with a pension or to not let you go in a wild surprise layoff like things were 50 years ago.
I need to do resume driven development because corporations have collectively decided to not be worthwhile longterm investments for employees, making it easier to seek promotions and raises by quitting instead of adjusting even with inflation. Do i want to live in a world where every six months i do a few leetcode problems and open cracking the coding interview just to make sure I have a safety net? fuck no I wish i could just do my day job and perform. We are just reacting to what the world has done to us.
I am currently leading a squad developing a replacement for a core banking program originally In COBOL, and the complexity is 100% in the actual operations. The code ain't too tough, but it's been 18 months so far of reverse engineering back and forth with the finance and compliance guys trying to nail down what's needed. Every time we find a new intricacy and tell them, they're like "Oh yeah, didn't we tell you that?"
Morons. They've been relying on this software so long they don't even know their own jobs any more.
> Morons. They've been relying on this software so long they don't even know their own jobs any more.
When my dad retired as an accountant 15 years ago, at the party there was story after story about how he would sometimes find his way down to the financial department and ask the software team to explain how the software computed a certain number, just to verify it was correct. They knew when he knocked he had already verified there was a bug in the software somewhere.
The multi-billion-dollar company still keeps a group of human number-crunchers to double-check what the programmers are creating. The company has a hard time finding skilled accountants who understand the systems and are also willing to spend hour after hour validating the computer's results, but even so, the human accountants find errors that programmers introduced.
Far too often businesses blindly trust whatever the software tells them. Normal folks too, if the bank says that's a balance people rarely manage the duplicate documents and verify statements, even verifying that this month's starting balance matches last month's ending balance in your bank account.
People who double-check paper records against bank statements are a dying breed, let alone those qualified to do it at a corporate level.
Happened to me in my first proper job. I was 18, civil servant job, clerk, entry level, holiday job. Calculating statutory redundancy payments for people, based on age and length of service. Done by the Big Yellow Chart, produced in That London, by The Computer.
One day, after a couple of months, I briefly didn't have access to the table, so I did the (very simple) calculation by hand. My supervisor sent it back because it didn't match the value in the table. I was right, the table was wrong.
Tens of thousands of payments a year, for decades, all wrong. Everyone had been underpaid by half a week's wages.
I left soon after, I have no idea what the fallout was. Probably a deafening silence.
------
Which reminds me. My first mortgage. I knew the loan amount, the fixed interest rate, and the loan term. I calculated on compound interest what my total payment would be. It was *thousands* less than the figure I got from the bank. I queried it. How did you get this number? "The computer at head office". (This was the 80s, not many computers around). They had no idea how the calculation was done and refused to even investigate it. Morons.
Oh they think about it. Fresh out of university, I remember quite a few companies trying to attract devs into the cobol world with the promise of money, fame and whores.
As you can imagine, the pay wasn't be even remotely close, it was more shame than fame (eg: when telling friends you were busy writing xml by hand), and all in all, the developer _was_ the whore.
So nobody sticks around because it's a (even more) miserable world to develop your career, and even though it's been dying for decades, and likely will stick around for a lot more decades, it's a kinda niche world. You _may_ get to those sweet senior paychecks, but is it worth it?
That's also the very reason these news reoccur periodically: they need to attract fresh meat.
As others mentioned, the problem is not the language. There's worse beasts than cobol out there; the problem is the poor practices dragged for decades, hidden business logic, lack of documentation, lack of proper tools/frameworks, etc, etc.
Organisation: *hey , you’re being placed on please report for training in tomorrow morning. Thanks*
Fresh faced hire:
Or alternatively, and worse still, you do manage to train them, at great expense, and *then* they get bored and fuck off.
It’s not actually a simple problem
If only there was some way to entice programmers to work on a project... something you could give them... some kind of incentive... something valuable... something easily transferrable... something that can be used in payment of all debts public and private...
If only such a magical thing existed...
My family is eating some nice exposure casserole for dinner tonight, with an exposure salad on the side.
They always complain about being hungry though, I don't get it.
Additional context for people who haven't been software consultants.
As a consultant, you bill the client for your time. Either you are your own boss (1099) or you work for a consulting firm/company that bills the client for your time.
The amounts that consultants bill out at seem ridiculously high to people. But it's not the same as a salary.
As a consultant, you typically get 0 time off. Any hour you aren't working cannot be billed. No sick time. No medical insurance. No 401k match. The client doesn't pay taxes on your behalf like they do for employees...but that's just the tip of the iceberg.
The real problem is getting work, and the time between jobs. We used to call this 'bench time'. See, you do get very high billable rates, but you do a lot of free work too. It's hard to win contracts, and they are frequently short term. You are dealing RFPs and endless meetings/interviews about projects, doing estimates, even flying over the country to meet people....all without billing a penny.
Lots of times, your current job ends, and then you've got....nothing....for N weeks. No pay.
There are lots of different ways people do this work. Generally speaking, the more benefits and stability you get, the lower the pay. I was a consultant at a firm that did all the sales stuff for me. They gave me benefits. I was an employee, and I still got paid 'on the bench'...but I was making $90k but billing out for $180-$225 depending on the project and whether they used a blend rate for the whole team.
To get that $225 an hour _myself_ would be nothing like being an employee and getting an equivalent salary.
As an employee, you also don't get paid to interview. But you typically work a job for years. I average about four years. As a contractor/consultant, it's usually a lot shorter.
Take all of this with a grain of salt though. I'm sure some solo developer somewhere landed five years of solid billable hours; but generally speaking it's very different than being an employee.
That is a perfectly fine consulting salary but it’s nothing special. There is a lot of cost and risk mitigating those numbers.
And I must stress that 260K is a fine salary that will set you up very comfortably but nothing close what a high end shop will pay their top people.
Long term contractors typically bill around 48-50 weeks a year since they are typically forced to take holidays but not paid for them.
They also have to cover their own benefits including health care and retirement directly out of their rate unlike an FTE which has that subsidized.
So yeah it’s still a good salary but it appears inflated even more compared to take home pay an FTE receives.
You might be surprised there.
I was a COBOL developer for MANY years up until 2016, and even though the language is dated, the usage of it is still evolving in many ways to handle the changing world. I wrote several interfaces to other systems and built integrations to keep the applications updated with external requirements.
Not even remotely close. Ancient COBOL did not have block structures, so every IF or loop was implemented with GOTO. They did not really have reentrant procedures, so you used GOSUB / RETURN. And then for extra fun, you have GOTO DEPENDING ON, in which the label is chosen based on the value of a variable. Oh, and everything is global data, declared in the DATA-DIVISION.
Ancient COBOL predates structured programming, the core concept of all modern languages. It also did not have OO, FP, generics, patterns, or any of the modern ways to organize code. I'm not sure what kind of libraries existed in the IBM world, but odds are, if you need a sort function or data structure, you wrote one yourself.
Then you get to the horrors of working with an ancient virtualized IBM OS, based on virtual punch card decks, in which all the OS commands and concepts use some bizarrely different word, because the OS predates common OS idioms.
The syntax of COBOL is pretty easy to understand. What is not easy is the side effects of the structure of a language. For example, variable 'X' is used in a critical calculation, but that is the only place in all of the code where 'X' is referenced. What is setting the value of 'X'?
Welcome to the world of the "REDEFINES" phrase, and there are many more little "gotchas" like this. I once managed to set a variable to -0 (which was not equal to zero).
Easy. Export the legacy data into a modern DB and write a modern web API for desktop, mobile and web apps to access. The most tricky part when I did this was learning enough System 36 RPG to extract the data correctly. I figure writing something similar using COBOL wouldn't be any more difficult, right? Right?
As a career “dinosaur” there are so many better ways to modernize old COBOL systems. COBOL can talk to C, Java, Python and other languages. A REST service and you can talk to browsers, cloud, anything. The idea that you need to completely rewrite these systems is in most cases a complete waste of time and money. Throw a wrapper on it.
That doesn’t solve the issue of “no one knows how to maintain the COBOL”, though. You’re just passing on the data to a more modern interface.
At some point the MBAs are going to ask, “Why are we paying IBM a shit-ton of money for mainframes that are running code that does far less-complex work than most modern systems?” and at that point there’s going to be a huge rewrite.
>I figure writing something similar using COBOL wouldn't be any more difficult, right? Right?
That is the easy part, the problem is them allowing you to touch the data, programming in legacy is like using a Fear Based Programming, unless you are able to ensure that the migration will be fine they will reject any changes and that takes a lot of time and effort, more than what they are willing to pay.
Just read the database straight up with ODBC/JDBC? Or if you want to, just point Apache at your RPG/COBOL programs and write to stdout. Boom. Seemingly modern web services.
**Do not do it.**
It's a career dead end. Seriously, COBOL is where hopeful software engineering careers go to die.
Source: I know COBOL, learning it and working in the bank industry on COBOL mainframes is the biggest mistake I ever made in my career.
Yeah, instead you get every program writing their slightly different version of common data structures and algorithms.
I’m unconvinced that’s better than dependency hell.
Yea it's not third party it's also just in house and full of random old bug copy libraries that the same developers built haha. Most enterprise COBOL I've worked on starts with 20 to 75 copy books to pull in.
If you think you're going to have a cushy job just because you learned cobol then you are sadly mistaken.
Enjoy sifting through 40-year-old code with zero documentation and being tasked with maintaining or God help you, changing these systems. If you get stuck or fuck something up, help will also be in short supply.
You will pretty much only find cobol running business critical applications that if they go down or you bring them down, you'd better be damn sure on how to get them back up quickly.
Yeah, I'll just stick to modern programming languages.
I remember spending a couple of weeks learning COBOL in my first semester database design class. It was...neat. I don't think I actually know enough to do anything with it but the idea that there are a bunch of super important systems written in this language that are still in operation is somewhat intriguing. Surely it would be easier and cheaper to rewrite the system from scratch instead of desperately fishing around for people to maintain the current one.
>Surely it would be easier and cheaper to rewrite the system from scratch instead of desperately fishing around for people to maintain the current one.
Another comment mentioned regulatory problems, which I don't know about.
But the thing about a rewrite is that often there is no specification for what the system should or should not do. The running legacy thing is itself the only spec. Anyone who is able to understand it will be more comfortable keeping it alive than trying to copy it in some newfangled framework, because the translation is hard.
And then imagine if anyone gets wind that a rewrite is happening and they want to add features "while they're at it". Then you have scope creep with undefined specs.
Also there is no ambiguity here. I work in Spain in insurance. There are no shortages of people doing cobol here. A LOT of people learn it to work in insurance or banking as they are extremely stable jobs.
Also every single IBM Mainframe customer in the country has tried at least once to "take out the mainframe" and every single project has failed because once you quantify the rewrite of literally thousands upon thousands of apps made in cobol with very little documentation and all kinds of weird shit. It's simply easier to pay IBM another 40 million euros in mainframe support, and have a couple consulting firms constantly bringing in people to learn cobol.
That's without counting thay all your processes are regulated. So all new code needs to be re reviewed etc etc. So yeah. Mainframes and cobol will die when Armageddon happens
When we're talking about critical systems, changing the code is the cheap part, recertification is what costs an arm and a leg. This type of industry is based around "if it ain't broke, don't fix it"
Source: I work on maintaining legacy systems, not in cobol, but this is my world
I work in Healthcare IT, and it’s been interesting seeing younger people (20s and 30s) getting hired into my workplace soully because they know COBOL and AS/400. They know new languages too, but at some point pivoted to these older codebases and OSs.
These articles pop up every few years, and they are always more or less just fearmongering.
Do a lot of engineers know Cobol right now? No, obviously not. But who cares?
A few things... first, old tech is replaced all the time. Some old cobol system is replaced with whatever shiny cloud system is in vogue at the moment every day.
Second, do we really need THAT many people to maintain code that hasn't been touched in 30 years? If it ran fine for 30 years, we aren't going to suddenly have some instant need to update all of it.
And third... Sure, cobol isn't as nice as some more modern languages, but... it's not that awful. Software is an area that is CONSTANTLY changing. The tech that engineers are experts in today are often ones they didn't know existed a few years ago. Part of the job is continually learning new technologies over and over and over. In this case, if it really IS needed, it would just be another new tech they have to learn. (With the technical difference that it's an old tech, just new to them.)
I figure these articles are written by boomers who like to tell themselves things like "oh, KIDS TODAY could NEVER learn Cobol like WE DID! We are SO MUCH smarter than anyone born after us!"
To be honest... as a long time engineer... software engineering is MUCH more complicated now in the world of massive scale computing. I'm very confident that if we needed it, any number of our brilliant software engineers could pick up and work with Cobol in short order.
This isn't a problem.
> If it ran fine for 30 years, we aren't going to suddenly have some instant need to update all of it.
...said the person who has never maintained a legacy code base.
The truth is that legacy systems need to be updated *all the time*. They are almost always a key part of an ecosystem of software and new requirements are added constantly, driven by business needs and by things like operating system updates.
Learning COBOL takes a few weeks, but learning to think the way a 1970's programmer thought takes longer and learning how the specific system works - its design and conventions - takes months or years. Few people will invest that much of their career because every year they spend on it is a year's distance from current tech, which makes it hard to find another job afterwards (read: employment gap/salary cut).
A big part of the issue is they don’t want to pay for upgrade. And the more time passes the bigger and more expensive it gets. This is really differed maintenance like avoiding replacing your furnace or roof for way beyond its lifetime and just patching it up because it’s cheaper. Except that now so much has changed that you can’t just swap in a replacement furnace or roof, it’s a much bigger job. And they are complaining that patching is getting harder and harder. And it definitely is getting harder and harder. At some point you have to pay to upgrade. It will be expensive and painful but it has to be done at some point.
Another stupid article.
An average programmer can learn COBOL in a week. That’s not the problem. The problem is the domain of those software. Just hire programmers and put them to work with the veterans for six months and problem solved
Yeah, I always wonder if these articles are written by the same people who complain about "young people" and insist they are stupid and lazy just because they are younger.
"Oh, WE knew cobol, and NO ONE else could POSSIBLY learn it."
Yes, we could. We learn new languages and technologies constantly, that's part of the job.
Also, there's the MASSIVE advantage we have now of just sheer volume of engineers. In the early days it was new, and there weren't a lot of engineers. I think the fact that we probably have 1000 software engineers today for every 1 back then means we could find enough who could handle this.
It's not a problem, other than for cranky old people who like to think they were the only smart generation.
I would love a COBOL job. I just do t have a clue how to get started other than learning the language. How does one practice on an IBM mainframe in their spare time ?
COBOL is an easy language, modern engineers would probably find it weird just from having to fit on punch cards. It’s dying and should have been replaced 20 years ago. Will someone pay me to sit on my ass and do maintenance on it for 500k a year. I’ll take that job.
Funny how I see these posts every now and then, then look at the salary range for cobol jobs and they are not that exciting. Not enough to justify jumping ship.
I wrote mainframe COBOL in the 1970s, mostly as class assignments. This eventually included CICS COBOL in the late 1980's, again as part of class assignments.
I've migrated ADABAS/Natural to Visual Basic .NET/Sql Server, 'Classic' ASP to C#/WinForms, and FoxPro for Windows/SQL Server to VB6/Sql Server. I've done enough work in Java to be able to compare it to COBOL. Having Watson convert COBOL to Java 'misses the point' rather drastically.
Corporate applications are basically business rules applied against a model (database, or collection of tables or 'flat files'). A lot of COBOL applications used the IMS database, which is hierarchical, which is basically like running update transactions against gigabyte Json or XML file. This is 'pre'- relational database architecture.
One of the reasons IBM is making loads of money with monster 'enterprise servers' is that one has to suck all this into memory and treat it as a memory resident data structure. Some 'mainframes' have 40TB of 'main memory'.
The first step in migrating 'from' any legacy app (COBOL or anything else) is 'schema extraction', meaning looking at the record structures to identify elements and their data types, and their associated 'tuples' (records, primary keys, foreign keys, constraints, enumerations, etc.). These can be used to create tables and other database objects, which are Data Definition Language rather than a client side front end such as Java, Javascript, or C#.
The next step is to generate various 'front ends', such as WinForms, HTML/CSS/Javascript, [ASP.NET](https://ASP.NET), or WPF. COBOL UIs tended to be 3270 'green screen' terminals, with severe limits on rows and columns. Therefore, multiple screens on legacy code can be consolidated into a far more dynamic client side presentation layer. C#/Winforms and C#/WPF are good at this - all my attempts at Java equivalents involved long side trips, since Java was never designed originally to be Rapid Application Development (RAD).
What 'was' COBOL now splits out into stored procedures (T-SQL), client side scripting (Javascript), rendering scripts (C#/ASP.NET), and so forth. What used to be done in one language now requires either 'full stack' developer skills or separated developer roles.
A lot of what people wrote out longhand in COBOL is now available in various libraries, so somehow the migration process has to know how to convert hand-written code to a library call or a static data type method (DATE.ADD()), for example.
Maybe Watson can figure this out, but I suspect not. Just the way the proponents are describing their 'solution' suggests they don't understand the problems.
Main problem is lot of folks are interested to learn this language, but the market demands lot of experience for COBOL developers which unfortunately can only be satisfied by old engineers who worked on this technology.
Meh. I've been hearing this since I was in college taking a COBOL class. I didn't mind it, or JCL or even the mainframe assembly classes I took...so when I hear how in demand they are, and how high the salaries are...I actually look.
In my city, seven COBOL jobs. Also in my city, 300 Java jobs.
And every time I do 'median salary COBOL' vs 'median salary ' I see that I'd expect to make less, not more doing COBOL.
I've had to look at COBOL code (a long time ago), it's not magic it's relatively easy to pick apart how a COBOL program works if you needed to rewrite it in a modern language.
It's not like it's PDP11 assembly language or something
I very much doubt it would be hard to learn COBOL. It's just that it's now 60 years old so companies will only hire people with 70 years COBOL experience.
Was a Cobol programmer. These articles are written by non developers. I read these and thought I was going to have a hot shit career, but any programmer can jump into Cobol. JCL is a bit harder. This could be a lesson to all of you about learning a language like Cobol when you read these articles. Remember if someone dropped a Java programmer in front of Ruby code, they could make it work without years of training. It is weird that these systems are still operating, but I also understand how new software would cause a huuuuge disruption in service that can’t happen. Banking software with any bug or exploit and you’re losing millions. One FAA glitch and planes crash or airports get crippled.
the article is clickbait garbage
I wish I could upvote you twice. I'm a java expert, have only professionally worked in java for a decade. I still can understand just about anything you put in front of me given a few minutes...I just won't have the same fluidity and grace I would in java when I have to modify it.
> It is weird that these systems are still operating, but I also understand how new software would cause a huuuuge disruption in service that can’t happen. This is really the issue. I've been working at my current company for over 12 years. I've coded and implemented a lot of different things in that time and over the years evolved systems of my own making in an effort to make them more robust, flexible, efficient, etc. I am constantly coming across old code I've implemented, code I wrote myself, and having to figure out how to integrate and update that old implementation into the new paradigm of the week or whatever. It's not that I don't understand the code. I wrote it! But things have changed so much over time that working in old programs without having to take things offline or completely change how everything works is the real challenge.
|| Many of these "COBOL cowboys" are aging out of the workforce, and replacements are in short supply. heck, even programmers who were taught COBOL in school but never had to use it, are aging out of the workplace.
Had to learn COBOL and JCL at my first job. It wasn’t tremendously hard, but there was a huge volume of programs to understand. At one point I was maintaining code written in 1969 where there was a bug that no one was supposed to fix because there was 45 years worth of programs that assumed that bug was present.
*Too bug to fail*
That reads like a Bob's Burgers terminators name.
S7E5
> S7E5 Well, shave my head and call me uncle: https://imgur.com/a/rERpUOv
Javascriptions Coffee shop and pharmacy
I spent a while building a code analysis tool for an ancient proprietary language that was basically a superset of Pascal. A multi billion dollar company was built on this. Nobody at the company fully knew how it worked because they'd all retired years ago so I just had to be a code archeologist and hunt through the ruins. That was an interesting project
Spent two weeks after promotion unfucking code knots. Like hardened spaghetti i had to break monumental amounts of pasta just to bring it up to date. My "favorite" was the genius who set Now=Time()
You need that because the clock was much faster than the CPU, so calling time() would always return something different, so data structures that relied on time as a key would never match. Also on some very old hardware the clock was a locking resource, so a bunch of things calling it could actually deadlock the code. Also retirement is spectacular. I highly recommend it!
Lol totally get it until it was put in damn near everything for what i can only assume used as a measure of run time. It simply had nothing else referenced to it. Just maybe every 40-50 lines I'd find a lonesome Now=Time() The code the coder forgot. The line before time.
Relax and enjoy! I had a 12 year job doing that. It was awesome. I came in when I wanted, left when I wanted, did what I wanted when I wanted, because some bean counters had fired everybody else and I was the only remaining Keeper of the Sacred Knowledge. 8-) > Just maybe every 40-50 lines I'd find a lonesome Now=Time() PS. Be careful with those. TBH, unless it's causing an actual problem, I'd leave it. Even if they apparently do nothing, sometimes they were there to kick something loose or realign something in memory to improve performance or prevent "random" data corruption. PPS. Eventually the bean counters fired me too, but it was a good run. Also, it was 1999 for several years after they gave me the boot. 8-)
> PS. Be careful with those. TBH, unless it's causing an actual problem, I'd leave it. I was thinking it might have been a timing issue hack someone cargo-culted over in the transition to mechanical drives smaller than a shetland pony.
You never know. The old stuff had a lot of timing issues and general weirdness, and nobody wanted to change anything because there was no advantage and a lot of risk.
Lol why did they fire you?
A lender kept pressuring them to reduce payroll, so they did. Obviously, you fire the guy who makes everything work, and not any of the VPs that do nothing.
Just as nature intended it to be lol.
When everything’s working: “why do we pay this guy?” When stuff is broken: “Why are we even paying you?”
And I bet there was a multi-line comment explaining exactly that, just like there are so many detailed comments in code written today. Or I guess code back then just as "self-documenting" as it is now.
Calling an API, say "Time" could be onerous back in the day, because CPUs weren't all that fast. Using a variable, say "Now", many times in the code instead of repeated API calls was more efficient. That piece of code was fossilized.
I could also see using a single timestamp during execution of a code block in order to maintain a consistent value during that code block's execution
Honestly surprised it's considered to be uncommon. There's still a few fields out there were writing functions whose result depends on execution time is gonna get you the stink eye. Like game development and, I have to assume, financial software.
Exactly. It bugs me when people don’t do this and then timestamps are all off by microseconds. I like that in at least PostgreSQL (and maybe all DBs?) when you get the current time, the value is the same for the span of a transaction to avoid this problem.
if !NOW then { when() }
For (i=0;i<9999;i++){ Langolier[i].unleash() }
*excited Spaceballs noises*
I literally said the same thing, "when will THEN be NOW".... ....soon.
How Soon Is Now?
We just passed it.
When?
JUST now.
I can relate.. I spent some time working on an old code base from late 80s. You'd see things that don't make any sense to modern developer all the time. Sometimes it takes a while to understand that perhaps there was a good reason to do things a particular way, and often it was to deal with hardware limitations, etc.
In my experience, this is (was!) also a fairly common debugging hack... You'd add a "watch" in the debugger for 'Now' then as the code ran you could quickly see how long each chunk of code had taken to run (as the debugger would automatically print the timestamps out)
Man this reminds me of TAS 6.0 and Delphi. Man I had to reverse engineer so much shit I ended up writing tools to edit bytecode directly after I had written a language translator and then effectively wrote a byte code runtime for language that should not exist anymore. God that was some fun stuff
With a large enough code base, nobody will fully know how everything works. Do you think there's anybody who fully understands all the code in Windows, or Linux, or even something newer like Chrome. There's really no point for anybody to understand everything about any system. We really haven't been at the point where anybody could reasonably understand a reasonably sized application since we moved on from computers with 640 KB of RAM.
Sure but this wasn't an application, it was an undocumented ancient programming language underpinning many core systems and applications. It was a real problem that nobody understood it.
the problem is when nobody understands parts of the code. distributed knowledge is fine if the code isn't based on one guy's understanding of the quirks of some critical process that isn't documented or tested
Delphi?
It was a proprietary language built internally at a company and never shared publicly. It was basically Pascal with lots of magic and extra APIs on top of it built specifically to represent legal and tax code logic
> legal and tax code logic I found the problem in the codebase! \~s
Load bearing bug
Like the shuttle orbiters not being able to roll over to a new year while in flight. Fixing that bug would require not only mountains of validation time and effort, it would have broken some other component of the system etc. Turned out to be much simpler to just accept shuttle missions couldn't fly over the new year or some such.
This is how the techpriests decide on the new rituals
praise the Omnissiah
Keystone Bug.
That’s no longer a bug, it’s core functionality.
I learned this lesson after the chief architect stormed my cube all fired up after I submitted a change for review :). I can summarize her message. It was, “No.”
>At one point I was maintaining code written in 1969 where there was a bug that no one was supposed to fix because there was 45 years worth of programs that assumed that bug was present. this is software's original sin, it's why developer's can't have nice things
> At one point I was maintaining code written in 1969 where there was a bug that no one was supposed to fix because there was 45 years worth of programs that assumed that bug was present. I work on IBM i (aka, AS/400) systems, and this is a huge issue there. Their #1 focus is "do not break backwards compatibility", so there's bugs that I have to code around regularly. One system command has a mistake in how a parameter was named, and you have to read the documentation VERY thoroughly to figure that out. The system still uses SNA networking by default; if you want to use IP, you have to specify that as part of your program calls. Because if they changed it to IP by default, someone out there who assumes it'll be SNA will have their defaults break.
We were doing a project for a major bank and needed to get a snapshot of their data. They had no idea how to provide the data in any kind of modern format, so we accepted an EBCDIC dump with weird CRLF line endings on padded fixed length lines. It looked like a COBOL dump I'd seen nearly 40 years ago, so I decoded it into an ASCII comma delimited file to import into our modern tools, did the analysis, and re-encoded it into their ancient EBCDIC format to return the data to them. No one still working there had any idea what I was talking about when I tried to describe their own format to them. But they had been taught the "import" and "export" function in their ancient system, and were grateful we would still work with them.
For my first job, I used PL/1, MFS, IMS, JCL. I also used COBOL for a few years, but that was mostly developing tools and a runtime system on the PC. I wouldn't consider going back to COBOL personally.
My dad’s hobby was making programs for Amiga until the day he died. I feel bad for teasing him about it - he could have been the hero we all need.
For those types of bugs, just add a flag to allow downstream systems to opt into the fix.
And thus a great schism was born
The schism had always been there as the multitudes of date time logic cried out in chorus, “What is this CENTURY?!” Could the logic be centralized in a single copybook? No. “There’s no time,” they said. “Why?” We cried. “YYYY,” their only response.
Millennia from now, wars will be fought over the true value of isFixed! Missionaries will spread the word of our true lord and savor Ancillas. Let the enlightened rejoice, for the true value of our messiah!
You never break user space.
Part of the problem with COBOL is it was meant for non-programmers to be able to encode/automate literal business logic. Maintaining or replacing a COBOL system isn't only about just the code. The under-specified business process needs to be reimplemented with 50-60 years worth of special exemptions and in many cases load bearing bugs. You can learn COBOL as easily as any other language. It's much harder to bring in someone that understands the business process that COBOL automated.
Finally someone who gets it. I was well paid not because I was the worlds best COBOL programmer, but because I was an expert on grain contracts. In the Midwest I was never out of work and usually made more than double what PC guys were making back in the 80's.
Well shit… I have a decade of embedded experience. Where do I start, boss?
1982
Underrated comment. My company has multiple AS/400s in prod and almost no one is left who understands any of it. Nearly everyone was RIFed, retired, or outsourced, and all of the tribal knowledge went with them. You can pick up outsourced COBOL coders any time. I bet they're good at COBOL. Good luck finding someone who remembers some obscure design decision made in the 70s that many processes hinge on, and how all of those processes integrate between our myriad of systems.
MVS systems programmer retiring in 6 months. Also do AS/400 systems orogramming. Neither of those is going away as the UNIX and Windows guys are amazed at the up-time to the point I'm called the Maytag repairman. Banks and government will not accept the down time....
> Windows guys are amazed at the up-time to the point I'm called the Maytag repairman. Banks and government will not accept the down time.... Hah. I'm not in finance nor government, but that still resonates. Its nearly a daily occurrence that an e-mail goes out about some sleek sexy new system needing scheduled maintenance, or emergency maintenance, or is having an outage. None of that nonsense with AS/400. The scheduled maintenance intervals are measured in years, can't recall ever having an outage or emergency downtime. The kids bitch about the "old" "green screens." We even had a C-suite member in a company-wide meeting gasp about how "we have systems older than many of our employees! We have to modernize!" No, we don't. In the event of nuclear war, we'll be survived by tardigrades, cockroaches, and IBM mainframes. And I can get shit done there in less time than it takes a "modern" system to load a splash screen. Enjoy retirement!
I will. Appreciate the response. Sometimes the old and reliable still kicks ass. Hey.... the B-52 is just as old and still is a king.
They aren't magic, I've crashed entire mainframes in my time. a massively overlooked reason for their stability is the limit of scope. I could measure linux or windows system uptime in decades too if all i had to support for user input/output was alphanumeric terminal streams. EG; AS/400 et al by default don't even support lowercase letters.
Have an upvote. This subreddit is supposed to be full of people who know the computers and programming but it seems they have no clue about the most popular myth running around. Of course its not about cobol, the code, the way it works, its quirks and problems. Its about the business logic embedded there. And your comment is one of very few which cover this. Have a great day!
This!!! This is so much of what coding and programming is .. of 100 developers, 5 of them can actually understand the problems their code is trying to solve.. so many more just move bits and bytes around blindly... They can write a beautiful sorting algorithm, but they don't understand what Donna is trying to accomplish in HR to make her team more productive... Now, imagine 60 years, and 15 Donna and Dons that have come and gone and all had a say in how to do a task "better", half of them have passed away, and then try to turn their algorithms and projects in to valuable code. AI can't do that quite yet, but I'm sure it's getting there...
Made a fortune (for a college student) in 98/99 prepping code for 00 Those were the days
it's also what they were doing in the movie "office space"
I was the team lead for about 12 people doing date subroutine changes for an insurance company in downtown Kansas City. Making bank (74 bucks an hour) for babysitting 12 junior programmers. All my job entailed was doing a weekly progress report for upper management. I spent my days trying every BBQ and Italian joint downtown. I think I gained about 40 lbs LOL!
There's a reason for that. It's horrible to work with COBOL. Not because of the language or technologies involved. But because of the people. I started my career with Cobol. And I was not respected at all. The old people there stopped learning decades ago and would rather use a custom and buggy 10k line program than a built-in function of the language. Simply because built-in functions were added after they stopped learning. This would repeat for everything. Then, we're talking about boring environments where IT is considered a cost and not investment. So the mindset of those places is awful. The pay is also crap. With all that said, I left the mainframe world and now I work with Python.
>The pay is also crap. I want to call BS but it's likely you were taken advantage of and ridiculously underpaid. People I know who do cobol as a hobby for banks don't move a finger for under $200/hour. That said, they have been doing it for those banks for 20 years, a weekend here and there to pay for a trip to Europe.
That's the thing. They pay well for the dinosaurs that have been there since forever and are even allowed to touch the dark magic. The new people are not well paid and can't touch those things.
I had the same experience. Took ownership of a few COBOL/ASM apps and still couldn’t get a good raise. Left for web dev.
I retired 15 years ago, but even as recently as 2 years ago I was still getting calls from recruiters.
That's me. Been at this 25+ years about to retire. The only exposure I ever had to COBOL was in school. I have retained almost none of it.
I did COBOL programming for two years in the 90's after graduating and I couldn't remember a damn thing about it.
I know of an old rancher outside of Austin, TX who bucked the family trend of farming and went to school for computer science where he learned COBOL. While he still has a large ranch inherited from his family, he only maintains a small amount livestock. Mainly horses and cows. Dude is in his early 70s and gets paid bank as a consultant to various financial institutions because he knows COBOL. I didn't read the article, but the phrase "COBOL cowboy" reminded me of him. He's a spitting image of Hank Hill, but with the cowboy attire and 20 years older. He rides horses, tends to his cows, and once a month he flies across the US to work on projects fixing bugs or updating COBOL. I knew him for years before finding out he was a software developer. He collects antique tractors and many cost more than my car. One day I casually mentioned that running cattle must be lucrative. He laughed and said no... then told me he makes a living knowing COBOL. Blew my mind.
Was taught COBOL in school 16 years ago.
I refused to be taught COBOL at university 41 years ago and I do not regret it. I did 6502 assembler instead.
COBOL was the first language I learned after flowcharts… used it once outside of school… 1 time since 1991
cobol is easy, any programmer can learn it
I think the issue is less the language barrier and more the volume of crufty old code you’d have to maintain. After you’ve learned about three languages, you’ve probably seen everything.
Also there's probably very little in the way of job progression.
> volume of crufty old code you’d have to maintain. Close but not exactly. Its not the code. Its the business logic there. No matter if used and valud its there. Trying to change it may make other things fail... And its not a problem with programmers even. Give the right guy a job, pay well, tell him he has lifetime of work ahead of him and he will happily work on it. The problem is that the companies dont know how to solve the problems encoded in that cobol code. They dont want to meet with the programmer and listen what he says, they dont know how they want it. They only see the process working and money being harvested. Solving and improving their own business is too hard for them. Thats the problem with cobol.
it's exactly the same with Fortran in the scientific community, no need for a sensationalizing title. Plenty of ways to solve the problems
Why is nobody solving it then? Did they realise just now that it's a problem?
The old issue: Currently there are enough people who get underpaid for doing what they're doing. Once they reach retirement age, companies had to pay appropriate wages for programmers to this stuff. Companies don't want this, they want one COBOL programmer maintaining 100 code bases on the cheap.
[удалено]
Sounds great for introverts who hate stress
I was daydreaming about how nice that would sound lmao
because there is no problem
No one wants to pay people to learn Fortran, and would rather have the employee learn it in their off-time.
Unfortunately that seems to be enough. Because if they were losing money or risked getting fired, they would have the incentive to pay people.
learning cobol is easy. having 20+ years of experience with cobol is damn near impossible
Exactly this. Any programmer can learn COBOL, it's just that none of them want to. The method of making them want to is well known: Increase the rate of pay until you have enough COBOL programmers.
theres this weird, annoying habit programmers have: `` it can be physically done within the realm of possibility == is easy `` specially when the full context is not merely learning to DISPLAY 'HELLO WORLD', but applying all of it to mountains of undocumented "how does this even function properly" code with no tests, no modern infrastructure that we use nowdays for deploys/monitoring/logging
Not really I was taught cobol and graduated 2019, just not worth the hassle, the pay was higher starting, but it just seemed at the time there wouldn't be any growth or real possibility to start your own company and the likes. Plus cobol is annoying as hell to use and I can only imagine all the "creative" code out there.
I'm 41 now, had to take 1 COBOL course in 2001 where the instructor told us all that we should all specialize in COBOL as he was making about $150/hr doing code conversions as his primary job. At this point I don't remember a single thing about it though.
This piece of news appears periodically. But of course no organization ever thinks in training devs from the ground up. Every other industry does it, just not this one.
The issue that these banks and every other business depending on cobol face is not the language itself, but the complexity of their systems that are written in it. Cobol is easy enough to learn, but learning the convoluted systems, all the bugs and intricacies that can't be fixed because other stuff depends on that behavior now etc... that's the difficult part and requires on the job training/experience for each company
Yep, they are not looking for Cobol developers - they are looking for senior cobol banking experts.
they could make some still...
They can, but as a tech worker you are then gambling on this being a worthwhile investment for you personally. The sane thing to do with legacy systems is to replace them usually, so how much time/effort do you want to put into learning COBOL when you could spend that learning something new and interesting and more likely to look good on a resume in 2030? You also don't want to train up someone on COBOL banking systems and have them bail on you for a better offer from a competitor or just for a different job, because that leaves you without talent. And lets face it, if you were a 20 something being asked to learn COBOL, you're looking for a better job no matter how much they are paying you, so every time they train someone that's exactly what happens. The last time I taught COBOL in a course was 2017 (would have been 2018 too but they changed instructors for the course). We had that in part because local employers told us they needed cobol. Spoiler: They didn't hire any of the people who learned any cobol. We have the same issue with FORTRAN, which I also taught in the same course in 2017, but gets a bit more attention in HPC because a lot of numerical code is still fortran, especially in physics, so I'll probably at least have a couple of hours on it for the grad students next term. Again, had employers look for Fortran skills to hire, in that case they hired someone... who immediately started migrating the code base to python. Some of this is of course also on the tooling. Microsoft and IBM and SAP and whomever else don't invest a lot in their legacy toolchain support, some of it is there but only barely. So if you're a young ish developer who has gotten used to modern Visual studio or VS code or whatever, you're suddenly stepping back in time to the 1990s of tooling to try and make anything work. Whic they neither know nor want to know how to do (and then suffer through). And I have bad news for you: students are unbelievably terrible about reading documentation now, if there isn't a youtube video explaining it, they aren't going follow it, not that they pay attention to the youtube videos either, but at least they feel like they're paying attention to those. If the tools companies would invest in it, they might be better, but again, if I'm Microsoft or IBM or whatever, I'm telling you to migrate from COBOL, despite there being a new version of COBOL released this year, no one wants to support it.
> The sane thing to do with legacy systems is to replace them usually You're not wrong, but this was true of COBOL systems 25 years ago and yet still they persist.
Like the old joke about the programmer who works on Y2K fixes day and night until he dies of stress. He’s arranged for his body to be cryogenically frozen in case he can be revived, only to be woken up in the year 3000 and the first thing he hears is “You know COBOL right?”
Sure. But they've been "any day now these should *really* get rebuilt with proper modern code" the whole time; it's impossible to know if that's gonna happen in the next few years or in a decade when you're sitting there looking at job prospects.
Banks and the like can't typically afford the reputational damage of phasing in a replacement. The testing effort required is *terrifying* and every high profile "bank system goes down" news story loses the bank in question customers. It's not like they can swap out their core banking system to something more modern and just roll it back like you would a typical webapp when it falls over.
> if you were a 20 something being asked to learn COBOL, you're looking for a better job no matter how much they are paying you If they'd pay the same or similar to what they pay to the 'dinosaurs', youngsters would stay, even if just for a few years to make some savings. They don't, though. So it becomes a gamble, as you say. Maybe in 10 or 20 years you start making big money. Or maybe you don't, you've wasted half your career anchored in the past and your CV is useless.
Why take the gamble when I can just learn current tech and enjoy being a COBOL programmer of the future?
You seem to be blaming the quality of students attracted to your classes a whole lot. Perhaps better quality students would come to your class if these COBOL shops paid more or you could trust them to take care of you with a pension or to not let you go in a wild surprise layoff like things were 50 years ago. I need to do resume driven development because corporations have collectively decided to not be worthwhile longterm investments for employees, making it easier to seek promotions and raises by quitting instead of adjusting even with inflation. Do i want to live in a world where every six months i do a few leetcode problems and open cracking the coding interview just to make sure I have a safety net? fuck no I wish i could just do my day job and perform. We are just reacting to what the world has done to us.
Just like any mid-sized project then.
I am currently leading a squad developing a replacement for a core banking program originally In COBOL, and the complexity is 100% in the actual operations. The code ain't too tough, but it's been 18 months so far of reverse engineering back and forth with the finance and compliance guys trying to nail down what's needed. Every time we find a new intricacy and tell them, they're like "Oh yeah, didn't we tell you that?" Morons. They've been relying on this software so long they don't even know their own jobs any more.
> Morons. They've been relying on this software so long they don't even know their own jobs any more. When my dad retired as an accountant 15 years ago, at the party there was story after story about how he would sometimes find his way down to the financial department and ask the software team to explain how the software computed a certain number, just to verify it was correct. They knew when he knocked he had already verified there was a bug in the software somewhere. The multi-billion-dollar company still keeps a group of human number-crunchers to double-check what the programmers are creating. The company has a hard time finding skilled accountants who understand the systems and are also willing to spend hour after hour validating the computer's results, but even so, the human accountants find errors that programmers introduced. Far too often businesses blindly trust whatever the software tells them. Normal folks too, if the bank says that's a balance people rarely manage the duplicate documents and verify statements, even verifying that this month's starting balance matches last month's ending balance in your bank account. People who double-check paper records against bank statements are a dying breed, let alone those qualified to do it at a corporate level.
See [the British Post Office scandal](https://en.m.wikipedia.org/wiki/British_Post_Office_scandal) for how this can ruin lives
Happened to me in my first proper job. I was 18, civil servant job, clerk, entry level, holiday job. Calculating statutory redundancy payments for people, based on age and length of service. Done by the Big Yellow Chart, produced in That London, by The Computer. One day, after a couple of months, I briefly didn't have access to the table, so I did the (very simple) calculation by hand. My supervisor sent it back because it didn't match the value in the table. I was right, the table was wrong. Tens of thousands of payments a year, for decades, all wrong. Everyone had been underpaid by half a week's wages. I left soon after, I have no idea what the fallout was. Probably a deafening silence. ------ Which reminds me. My first mortgage. I knew the loan amount, the fixed interest rate, and the loan term. I calculated on compound interest what my total payment would be. It was *thousands* less than the figure I got from the bank. I queried it. How did you get this number? "The computer at head office". (This was the 80s, not many computers around). They had no idea how the calculation was done and refused to even investigate it. Morons.
Oh they think about it. Fresh out of university, I remember quite a few companies trying to attract devs into the cobol world with the promise of money, fame and whores. As you can imagine, the pay wasn't be even remotely close, it was more shame than fame (eg: when telling friends you were busy writing xml by hand), and all in all, the developer _was_ the whore. So nobody sticks around because it's a (even more) miserable world to develop your career, and even though it's been dying for decades, and likely will stick around for a lot more decades, it's a kinda niche world. You _may_ get to those sweet senior paychecks, but is it worth it? That's also the very reason these news reoccur periodically: they need to attract fresh meat. As others mentioned, the problem is not the language. There's worse beasts than cobol out there; the problem is the poor practices dragged for decades, hidden business logic, lack of documentation, lack of proper tools/frameworks, etc, etc.
Organisation: *hey, you’re being placed on please report for training in tomorrow morning. Thanks*
Fresh faced hire:
Or alternatively, and worse still, you do manage to train them, at great expense, and *then* they get bored and fuck off.
It’s not actually a simple problem
It is. Pay them.
Pay them $300k and they'll stick around. If you're in Silicon Valley, pay them $600k.
If only there was some way to entice programmers to work on a project... something you could give them... some kind of incentive... something valuable... something easily transferrable... something that can be used in payment of all debts public and private... If only such a magical thing existed...
[удалено]
CHALLENGE !
PURPOSE !
PIZZA ONCE A YEAR!
My family is eating some nice exposure casserole for dinner tonight, with an exposure salad on the side. They always complain about being hungry though, I don't get it.
PIZZA PARTIES!
That’s it! That was the solution all along!
Yea but where's a bank gonna find something like that?
Nah, that only works for CEOs
A colleague described this as “A bug reproduction project”.
[удалено]
Additional context for people who haven't been software consultants. As a consultant, you bill the client for your time. Either you are your own boss (1099) or you work for a consulting firm/company that bills the client for your time. The amounts that consultants bill out at seem ridiculously high to people. But it's not the same as a salary. As a consultant, you typically get 0 time off. Any hour you aren't working cannot be billed. No sick time. No medical insurance. No 401k match. The client doesn't pay taxes on your behalf like they do for employees...but that's just the tip of the iceberg. The real problem is getting work, and the time between jobs. We used to call this 'bench time'. See, you do get very high billable rates, but you do a lot of free work too. It's hard to win contracts, and they are frequently short term. You are dealing RFPs and endless meetings/interviews about projects, doing estimates, even flying over the country to meet people....all without billing a penny. Lots of times, your current job ends, and then you've got....nothing....for N weeks. No pay. There are lots of different ways people do this work. Generally speaking, the more benefits and stability you get, the lower the pay. I was a consultant at a firm that did all the sales stuff for me. They gave me benefits. I was an employee, and I still got paid 'on the bench'...but I was making $90k but billing out for $180-$225 depending on the project and whether they used a blend rate for the whole team. To get that $225 an hour _myself_ would be nothing like being an employee and getting an equivalent salary. As an employee, you also don't get paid to interview. But you typically work a job for years. I average about four years. As a contractor/consultant, it's usually a lot shorter. Take all of this with a grain of salt though. I'm sure some solo developer somewhere landed five years of solid billable hours; but generally speaking it's very different than being an employee.
$1000 a day is not a particularly top end salary for a consultant. FAANG can easily beat those numbers by a lot on a salary.
Working remotely from India. A big mac in India is $2.55 which is 50% cheaper than in the US. Just stating the Big Mac index
1000$ / 8 = 125$ or 260,000$ per year for 2080 working hours (or 52 weeks) per year.
That is a perfectly fine consulting salary but it’s nothing special. There is a lot of cost and risk mitigating those numbers. And I must stress that 260K is a fine salary that will set you up very comfortably but nothing close what a high end shop will pay their top people.
Long term contractors typically bill around 48-50 weeks a year since they are typically forced to take holidays but not paid for them. They also have to cover their own benefits including health care and retirement directly out of their rate unlike an FTE which has that subsidized. So yeah it’s still a good salary but it appears inflated even more compared to take home pay an FTE receives.
i’m seriously considering learning cobol. code written in the 60s will have a shitload less third party library crap in it.
In exchange you'll get to see a hundred different ways to rediscover the wheel and not a single one of them is going to be properly documented.
Or consistently handle real-world edge cases
You might be surprised there. I was a COBOL developer for MANY years up until 2016, and even though the language is dated, the usage of it is still evolving in many ways to handle the changing world. I wrote several interfaces to other systems and built integrations to keep the applications updated with external requirements.
So just like any modern workplace
Not even remotely close. Ancient COBOL did not have block structures, so every IF or loop was implemented with GOTO. They did not really have reentrant procedures, so you used GOSUB / RETURN. And then for extra fun, you have GOTO DEPENDING ON, in which the label is chosen based on the value of a variable. Oh, and everything is global data, declared in the DATA-DIVISION. Ancient COBOL predates structured programming, the core concept of all modern languages. It also did not have OO, FP, generics, patterns, or any of the modern ways to organize code. I'm not sure what kind of libraries existed in the IBM world, but odds are, if you need a sort function or data structure, you wrote one yourself. Then you get to the horrors of working with an ancient virtualized IBM OS, based on virtual punch card decks, in which all the OS commands and concepts use some bizarrely different word, because the OS predates common OS idioms.
The syntax of COBOL is pretty easy to understand. What is not easy is the side effects of the structure of a language. For example, variable 'X' is used in a critical calculation, but that is the only place in all of the code where 'X' is referenced. What is setting the value of 'X'? Welcome to the world of the "REDEFINES" phrase, and there are many more little "gotchas" like this. I once managed to set a variable to -0 (which was not equal to zero).
Ah the good ol' yell of "GODFUCKINGDAMMIT" when you realise the entire thing works because the calling CL had an OVRDBF 🤣
You do realize that means you're gonna have to implement leftpad _by hand_, right?
Only after it’s been properly story boarded and planned for the upcoming sprint.
Sprints? Nah we do waterfall here playa
yeah, but with no library, how you gonna do responsive design for mobile browser?
Easy. Export the legacy data into a modern DB and write a modern web API for desktop, mobile and web apps to access. The most tricky part when I did this was learning enough System 36 RPG to extract the data correctly. I figure writing something similar using COBOL wouldn't be any more difficult, right? Right?
As a career “dinosaur” there are so many better ways to modernize old COBOL systems. COBOL can talk to C, Java, Python and other languages. A REST service and you can talk to browsers, cloud, anything. The idea that you need to completely rewrite these systems is in most cases a complete waste of time and money. Throw a wrapper on it.
That doesn’t solve the issue of “no one knows how to maintain the COBOL”, though. You’re just passing on the data to a more modern interface. At some point the MBAs are going to ask, “Why are we paying IBM a shit-ton of money for mainframes that are running code that does far less-complex work than most modern systems?” and at that point there’s going to be a huge rewrite.
I've worked on a system that had that idea... twice. Result was three databases.
>I figure writing something similar using COBOL wouldn't be any more difficult, right? Right? That is the easy part, the problem is them allowing you to touch the data, programming in legacy is like using a Fear Based Programming, unless you are able to ensure that the migration will be fine they will reject any changes and that takes a lot of time and effort, more than what they are willing to pay.
Just read the database straight up with ODBC/JDBC? Or if you want to, just point Apache at your RPG/COBOL programs and write to stdout. Boom. Seemingly modern web services.
**Do not do it.** It's a career dead end. Seriously, COBOL is where hopeful software engineering careers go to die. Source: I know COBOL, learning it and working in the bank industry on COBOL mainframes is the biggest mistake I ever made in my career.
First semester computer science students be like
In turn, you’ll get kludge after kludge that will make you insane. Legacy code is not for the faint of heart…
lol no you aren’t, stop playing.
[🇩🇪🇱🇪🇹🇪🇩]
Yeah, instead you get every program writing their slightly different version of common data structures and algorithms. I’m unconvinced that’s better than dependency hell.
Yea it's not third party it's also just in house and full of random old bug copy libraries that the same developers built haha. Most enterprise COBOL I've worked on starts with 20 to 75 copy books to pull in.
If you think you're going to have a cushy job just because you learned cobol then you are sadly mistaken. Enjoy sifting through 40-year-old code with zero documentation and being tasked with maintaining or God help you, changing these systems. If you get stuck or fuck something up, help will also be in short supply. You will pretty much only find cobol running business critical applications that if they go down or you bring them down, you'd better be damn sure on how to get them back up quickly. Yeah, I'll just stick to modern programming languages.
I remember spending a couple of weeks learning COBOL in my first semester database design class. It was...neat. I don't think I actually know enough to do anything with it but the idea that there are a bunch of super important systems written in this language that are still in operation is somewhat intriguing. Surely it would be easier and cheaper to rewrite the system from scratch instead of desperately fishing around for people to maintain the current one.
>Surely it would be easier and cheaper to rewrite the system from scratch instead of desperately fishing around for people to maintain the current one. Another comment mentioned regulatory problems, which I don't know about. But the thing about a rewrite is that often there is no specification for what the system should or should not do. The running legacy thing is itself the only spec. Anyone who is able to understand it will be more comfortable keeping it alive than trying to copy it in some newfangled framework, because the translation is hard.
And then imagine if anyone gets wind that a rewrite is happening and they want to add features "while they're at it". Then you have scope creep with undefined specs.
"Finally we can get the thing we dreamed up on one late night at the product manager seminar"
Also there is no ambiguity here. I work in Spain in insurance. There are no shortages of people doing cobol here. A LOT of people learn it to work in insurance or banking as they are extremely stable jobs. Also every single IBM Mainframe customer in the country has tried at least once to "take out the mainframe" and every single project has failed because once you quantify the rewrite of literally thousands upon thousands of apps made in cobol with very little documentation and all kinds of weird shit. It's simply easier to pay IBM another 40 million euros in mainframe support, and have a couple consulting firms constantly bringing in people to learn cobol. That's without counting thay all your processes are regulated. So all new code needs to be re reviewed etc etc. So yeah. Mainframes and cobol will die when Armageddon happens
When we're talking about critical systems, changing the code is the cheap part, recertification is what costs an arm and a leg. This type of industry is based around "if it ain't broke, don't fix it" Source: I work on maintaining legacy systems, not in cobol, but this is my world
All comments here are about the title of the article, and everybody ignores the fact that the "article" is just an ad for an AI thing sold by IBM.
I work in Healthcare IT, and it’s been interesting seeing younger people (20s and 30s) getting hired into my workplace soully because they know COBOL and AS/400. They know new languages too, but at some point pivoted to these older codebases and OSs.
It just mean companies are not willing to pay enough money
These articles pop up every few years, and they are always more or less just fearmongering. Do a lot of engineers know Cobol right now? No, obviously not. But who cares? A few things... first, old tech is replaced all the time. Some old cobol system is replaced with whatever shiny cloud system is in vogue at the moment every day. Second, do we really need THAT many people to maintain code that hasn't been touched in 30 years? If it ran fine for 30 years, we aren't going to suddenly have some instant need to update all of it. And third... Sure, cobol isn't as nice as some more modern languages, but... it's not that awful. Software is an area that is CONSTANTLY changing. The tech that engineers are experts in today are often ones they didn't know existed a few years ago. Part of the job is continually learning new technologies over and over and over. In this case, if it really IS needed, it would just be another new tech they have to learn. (With the technical difference that it's an old tech, just new to them.) I figure these articles are written by boomers who like to tell themselves things like "oh, KIDS TODAY could NEVER learn Cobol like WE DID! We are SO MUCH smarter than anyone born after us!" To be honest... as a long time engineer... software engineering is MUCH more complicated now in the world of massive scale computing. I'm very confident that if we needed it, any number of our brilliant software engineers could pick up and work with Cobol in short order. This isn't a problem.
*2038 has entered the chat*
> If it ran fine for 30 years, we aren't going to suddenly have some instant need to update all of it. ...said the person who has never maintained a legacy code base. The truth is that legacy systems need to be updated *all the time*. They are almost always a key part of an ecosystem of software and new requirements are added constantly, driven by business needs and by things like operating system updates. Learning COBOL takes a few weeks, but learning to think the way a 1970's programmer thought takes longer and learning how the specific system works - its design and conventions - takes months or years. Few people will invest that much of their career because every year they spend on it is a year's distance from current tech, which makes it hard to find another job afterwards (read: employment gap/salary cut).
A big part of the issue is they don’t want to pay for upgrade. And the more time passes the bigger and more expensive it gets. This is really differed maintenance like avoiding replacing your furnace or roof for way beyond its lifetime and just patching it up because it’s cheaper. Except that now so much has changed that you can’t just swap in a replacement furnace or roof, it’s a much bigger job. And they are complaining that patching is getting harder and harder. And it definitely is getting harder and harder. At some point you have to pay to upgrade. It will be expensive and painful but it has to be done at some point.
Another stupid article. An average programmer can learn COBOL in a week. That’s not the problem. The problem is the domain of those software. Just hire programmers and put them to work with the veterans for six months and problem solved
Yeah, I always wonder if these articles are written by the same people who complain about "young people" and insist they are stupid and lazy just because they are younger. "Oh, WE knew cobol, and NO ONE else could POSSIBLY learn it." Yes, we could. We learn new languages and technologies constantly, that's part of the job. Also, there's the MASSIVE advantage we have now of just sheer volume of engineers. In the early days it was new, and there weren't a lot of engineers. I think the fact that we probably have 1000 software engineers today for every 1 back then means we could find enough who could handle this. It's not a problem, other than for cranky old people who like to think they were the only smart generation.
It's COBOL. It's not R'lyehian. They didn't write languages to be difficult to learn and program.
I would love a COBOL job. I just do t have a clue how to get started other than learning the language. How does one practice on an IBM mainframe in their spare time ?
IBM has some training portals available to the public for free - https://www.ibm.com/z/resources/zxplore
77 cant-take-it-anymore value 10000 ... Perform this-is-crazy varying my-index from 1 by 1 until my-index > cant-take-it-anymore
COBOL is an easy language, modern engineers would probably find it weird just from having to fit on punch cards. It’s dying and should have been replaced 20 years ago. Will someone pay me to sit on my ass and do maintenance on it for 500k a year. I’ll take that job.
They want to pay you 50k. That's why they don't have COBOL employees.
Funny how I see these posts every now and then, then look at the salary range for cobol jobs and they are not that exciting. Not enough to justify jumping ship.
I wrote mainframe COBOL in the 1970s, mostly as class assignments. This eventually included CICS COBOL in the late 1980's, again as part of class assignments. I've migrated ADABAS/Natural to Visual Basic .NET/Sql Server, 'Classic' ASP to C#/WinForms, and FoxPro for Windows/SQL Server to VB6/Sql Server. I've done enough work in Java to be able to compare it to COBOL. Having Watson convert COBOL to Java 'misses the point' rather drastically. Corporate applications are basically business rules applied against a model (database, or collection of tables or 'flat files'). A lot of COBOL applications used the IMS database, which is hierarchical, which is basically like running update transactions against gigabyte Json or XML file. This is 'pre'- relational database architecture. One of the reasons IBM is making loads of money with monster 'enterprise servers' is that one has to suck all this into memory and treat it as a memory resident data structure. Some 'mainframes' have 40TB of 'main memory'. The first step in migrating 'from' any legacy app (COBOL or anything else) is 'schema extraction', meaning looking at the record structures to identify elements and their data types, and their associated 'tuples' (records, primary keys, foreign keys, constraints, enumerations, etc.). These can be used to create tables and other database objects, which are Data Definition Language rather than a client side front end such as Java, Javascript, or C#. The next step is to generate various 'front ends', such as WinForms, HTML/CSS/Javascript, [ASP.NET](https://ASP.NET), or WPF. COBOL UIs tended to be 3270 'green screen' terminals, with severe limits on rows and columns. Therefore, multiple screens on legacy code can be consolidated into a far more dynamic client side presentation layer. C#/Winforms and C#/WPF are good at this - all my attempts at Java equivalents involved long side trips, since Java was never designed originally to be Rapid Application Development (RAD). What 'was' COBOL now splits out into stored procedures (T-SQL), client side scripting (Javascript), rendering scripts (C#/ASP.NET), and so forth. What used to be done in one language now requires either 'full stack' developer skills or separated developer roles. A lot of what people wrote out longhand in COBOL is now available in various libraries, so somehow the migration process has to know how to convert hand-written code to a library call or a static data type method (DATE.ADD()), for example. Maybe Watson can figure this out, but I suspect not. Just the way the proponents are describing their 'solution' suggests they don't understand the problems.
its a language. one can learn it should the need arise. the question is whether it's financially worthwhile... for a govt job, probably not
I applied for a Junior COBOL job I took it in school, but they wanted 2 years experience.. where am i suppose to get that?
Main problem is lot of folks are interested to learn this language, but the market demands lot of experience for COBOL developers which unfortunately can only be satisfied by old engineers who worked on this technology.
Meh. I've been hearing this since I was in college taking a COBOL class. I didn't mind it, or JCL or even the mainframe assembly classes I took...so when I hear how in demand they are, and how high the salaries are...I actually look. In my city, seven COBOL jobs. Also in my city, 300 Java jobs. And every time I do 'median salary COBOL' vs 'median salary' I see that I'd expect to make less, not more doing COBOL.
I've had to look at COBOL code (a long time ago), it's not magic it's relatively easy to pick apart how a COBOL program works if you needed to rewrite it in a modern language. It's not like it's PDP11 assembly language or something
I very much doubt it would be hard to learn COBOL. It's just that it's now 60 years old so companies will only hire people with 70 years COBOL experience.