In my experience the well paid COBOL devs are those with 20+ years of experience, often in one specific system, often bumped by being re-hired a bunch of times for the same position. I've been doing COBOL since 2018 and younger devs my age (late 20s, early 30s) with a few years of experience make decent money, but the average is bumped by the teams having a lot of devs near retirement age.

If you want to learn:

The language isn't very complicated. I'd recommend grabbing the Visual Cobol for Windows trial just to get coding (and then shunning anything MicroFocus when you are done ;) ) https://www.microfocus.com/en-us/products/visual-cobol/overv...

If you want to/will end up tinkering with IBM systems, check out Jan Sądek's Mainframe Playground: https://mainframeplayground.neocities.org/

For running COBOL on VMS, comp.os.vms is a common place to hang out https://groups.google.com/g/comp.os.vms?pli=1 A dev named Remy documented his first steps on OpenVMS and it was a great help when starting out: https://raymii.org/s/tags/vms.html

There is some actual training material from firms specializing in COBOL training floating around, but they are mostly IBM and/or MicroFocus documentation with some suggested example programs.

I hope the resources above are useful and good luck!

Or not. It's a free world. Do what you want. But the purpose of COBOL isn't to show off your hot coding chops. No No. That's why ${DEITY} invented Lisp. COBOL is intended to clearly communicate how data is to be processed for business applications. And it does that reasonably well.

Is that experience in COBOL at that point, or more the quirks of the software, in the way I don't have 20 years of graphic design experience, I have more like 5ish paired with relearning the various changes to the UI, shortcuts, and extra features that get added or shifted out to other apps?

In some cases well paid can mean breaking $1 million. In other geographical areas or domains a well paid senior is $150k. The range of well paid is so wide it's not even worth mentioning without a number.

There's essentially only one employer they're worth that much to.

This is Hercules, an emulator for old mainframes. They also have COBOL and other important languages like JCL, the job control language.

Here the "turnkey" distribution that installs everything for you: https://wotho.ethz.ch/tk4-/

A mainframe community from youtube: https://www.youtube.com/c/moshix

Have fun.

Maybe start small. There were COBOL implementations for pretty much every 8-bit computer in the 80's. Think Commodore 64, Apple ][, or whatever emulated environment works for you.

Because they were designed for complete beginners, they often came with very detailed, very easy to comprehend manuals. Many of which are available as PDFs online today. And there was no end of third-party books to help you along, which may be available from Biblio, or whatever your favorite used book source is.

Getting a feel for COBOL from these baby steps can help you decide if you want to advance into full big iron COBOL development.

This also applies to FORTRAN, APL, and other older languages.

Yeah, "curve" might be a little generous here. It's more like a cliff from what limited I remember of my short lived mainframe stint.

Start from nothing, and make tiny baby steps. Target a short term milestone. Learn how to use the documentation. Even if you start slower than people who take shortcuts,you end up being faster because you have a much deeper undestanding

Learning COBOL, even in a "real" environment, isn't going to be the jumpstart that you're hoping for by itself.

Beware, maintaining those systems is absolute hell and the companies experiencing exodus are working their people into the ground because the workload is crushing them and they can't find replacements.

A good friend of mine is an engineering director at a company that runs a massive COBOL mainframe platform and he always half jokes with me about picking it up. The money isn't that great at his company and the problems they have maintaining the system just blow my mind. The entire company sounds fundamentally unsustainable long term but they're running critical payments infrastructure.

I'm thinking of the Elixir->COBOL like this: https://github.com/TheFirstAvenger/cobol_to_elixir

Was speaking with the author about a year ago and he was having really good success with it.

I like this idea of writing Elixir and outputting COBOL. That way it can interface with the operating environment (CICS, IMS) exactly as a natively written COBOL program does. Not that COBOL syntax is particularly hard to learn one by one, but as a whole isn't very memorable. Why learn a programming language with peculiarities like a natural language when I can use something concise that translates to it? There may not need to be a step to eliminate the COBOL output step any more than a language that uses C or js as a target.

I've only seen two kinds of CICS programs in the wild: 1. screen I/O using preformatted BMS maps, 2. transactional with input buffer and output buffer. A third kind was one I wrote for sending dynamically generated terminal stream data for a hypertext online documentation system.

Any of these could be written in Elixir with appropriate libraries and translators. The company I worked at generated the BMS maps and COBOL source from assembling program components with an inclusion/override macro processor and wysiwyg editors--think Visual Basic for mainframes targeting both CICS and IMS.

Where you're going to hit major issue is with COBOL running under the likes of CICS or IMS, where sure, you can use some more recent languages, but what you'll get in the end will be possibly even worse because now you'll have to find Java programmer who knows CICS.

And CICS or IMS aren't that easy to replace.

Please tell me its not a payroll company.

My first dev job was COBOL on a Unisys mainframe. When the volume of "omg we need COBOL devs" articles got loud, I looked into what was available. The compensation graph for COBOL positions approximately matches those of any other dev job. You can do as well (or better) as a Python dev or Node dev or whatever.

The key to making more money is in specialization. The highest-paying jobs are looking for experience with specific combinations of technologies.

But being a Python dev has the added advantage of not having to deal with COBOL. ...speaking as someone who used Unisys' STRING/UNSTRING OS functions to implement input variable interpolation in COBOL because it has no native string operators or data type.

In fact, they gave themselves a goal of avoiding making it into a programming language, except unfortunately real life requirements meant it had to gather such features quickly. Other infamous components came because of need to specify in line all sorts of metadata for I/O, because the OS might not have a place to store it - this caused the infamous DD statement that /bin/dd is a joking refence to.

In retrospective, one of the leads on JCL mentioned that they should have instead gone straight for a full programming language, that this way it would have better design.

ed /s

Well, you can invoke AIX and run ed, it works, but yes, ISPF, running in a 3270 terminal, is pretty weird. That being said, it's pretty much very interactive even under horrible latency because it sends the entire screen every repaint.

3270 is, in a retro way, what the web 1.0 would look like if we were limited to monospaced characters.

https://medium.com/the-technical-archaeologist/hello-world-o...

I've done this before - translate green screen apps to ASP.NET. In my case, the company had (retiring) IT staff read the cobol and give us good "plain english". The actual ASP.NET code was trivial. That said, my one caveat is I don't feel like any language today has the longevity of these systems. That code was ASP.NET 3 MVC - new at the time, but outdated now. What stack do I pick today that will still be running in 30 years? HTML+JS+NodeJS seems the most likely candidate IMO, but then you get into the various frameworks-du-jur and it sort of falls apart. Would love HN opinions.

The data model is fixed width flatfiles with very specific access and index methods. There are 50 years of workarounds applied in there. Whatever code you end up with will still need to communicate with all the other stuff, so the data model can't change untill you got everything touching it in the new language.

The edge cases are a second problem. The code runs well in a very practical sense, as every major bug relevant for the end user has been fixed or worked around ages ago. Or it became the correct behaviour by sheer overwhelming force. You replace something insane, then find out you broke another system that had counterbalancing insanity. Worst case, it will run for a few months, silently corrupting data. Next tax round or year end, some report says something strange, and subsequent troubleshooting uncovers major doodoo. No, the taxman wont wait on your bugfix.

Then there is the sheer volume of code. 10 million lines is small scale. You can spend your whole carreer rewriting everything in the most trivial way, and 40 year later find you're not even close to done. There will be multiple failed rewrites in there, causing massive lavaflow architecture problems.

> HTML+JS+NodeJS seems the most likely candidate IMO

So that my bank can run npm install leftpad on their payment processors.

Please tell me this is parody.

What's wrong with Java that COBOL doesn't suffer from exactly?

It's just moving business data into and out of, in many cases still file based records (but maybe we can upscale to SQL). So, if you can read the COBOl and implement correctly in the next blessed language (with tests).

Harder part is to meet the folks that can get you those gigs than actually doing the gigs.

Of all languages, js is by far the most volatile.

If Node.js is even still used in 30 years it won't look anything like today's Node.js.

This is such a backward mindset, though. Software evolves. Ecosystems evolve. Perhaps most importantly, security risks and surface areas evolve (which in part necessitates the prior points).

There is no good reason for systems to stagnate over three decades. Software isn't construction, it's gardening, and it requires constant maintenance and attention.

Software is like construction, you don't demolish everything and start from scratch just because it's a little, or very old.

Discarding everything and rewriting in another language is a expensive and error prone process.

To cite the excellent Joel blog:

> the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

same reason we are flying 737 aircraft and chinook helicopters, well after we tried concordes and space shuttles.

see "Web Design: the first 100 years" for more: https://idlewords.com/talks/web_design_first_100_years.htm

I did learn one thing, and that was COBOL has one up on 'goto'. Check out the control flow statement: MOVE NEXT SENTENCE. It's basically a goto, but it doesn't jump to a label, per se. Instead, it jumps to the next period in the source. Yes, in a big, blocky, verbose language like COBOL, where everything is in UPPER CASE, you're now looking for a teeny tiny period that is easily lost in the verbiage. Hands down, my least favorite programming language construct ever.

In more "modern" COBOL's like COBOL-85, there is actually a "CONTINUE" which is essentially a no-op.

Some COBOL shops instituted a "one-period-per-paragraph" rule (on the last statement in a paragraph) to avoid some of this. And COBOL-85 (thankfully) added scope delimiters (i.e. END-IF) to help avoid the issues with periods.

That problem happens with any transpiled language really, now you have all the problems of the new language and all the problems of the target language, and you need to fix "supposedly compiled" output by hand sometimes.

UNIX just considers that a file/stdin/stdout/stderr is a sequence of binary octets of arbitrary size, any information on how to deal with it is left entirely to the program.

In a way, IBM VSAM and other record access methods are more like tables with types that a UNIX-like file sytem.

As an aside I still have a zero-day for ICL mainframes running Gerorge that's decades old now and taking to my grave.

After getting some confidence you will be ready to begin your first COBOL job where you will open up the codebase to try and get familiar and immediately realize with shock and horror what you have committed to do. The hell and chaos of real world legacy COBOL all consuming.

You then sit there, day after day, counting characters and cursing your predecessor for not having that foresight to realize that a number might grow beyond 999. Daydreaming of a time when you didn't know so much about fixed length records, a time when you were happy.

My dad was a COBOL developer in the 60s and 70s, and I asked him about this during the Y2K panic. Back then, the cost per byte was extremely high. Even if they had thought people would be foolish enough to keep systems running for decades, they still would have gone with 2 digits for the year because they needed those bits for other things.

Looking up the numbers now, in 1969 IBM was selling magnetic disk drives for circa $1/KB[1] at a time when programmers were making ~$200/week[2]. Top data speed was something like 300KB/s. The CPUs processing the data cost the equivalent of 5-10 programmer's salaries to rent. So throwing out the century, a 25% savings on date data storage, was a no-brainer. Not just for the tech people, but from a management perspective. Imagine asking, "How about we fire a couple of our developers so we can buy another drive and make sure this is easy to develop on 50 years from now?"

[1] https://www.ibm.com/ibm/history/exhibits/storage/storage_231...

[2] https://fraser.stlouisfed.org/title/industry-wage-survey-lif...

This is 100000% true. Any decades-old private codebase is going to be a horror show. A friend of mine works for a COBOL-based payment processor and it sounds like the seventh layer of hell working there.

More power to those that want to chase the money (which isn't really that great tbh, the mean COBOL developer brings home less than 100k[0].) , but go into eyes wide open. If you're gonna sell your soul for the paycheck, Amazon pays much better.

0: https://www.ziprecruiter.com/Salaries/Cobol-Programmer-Salar...

If you just want to have fun with older tech that's totally fair.

Java pays well because handling legacy Java is awful, full of foot guns and a pain to maintain. Possibly more that COBOL.

In the U.S., sometimes those jobs are in silicon valley or New York, but sometimes it's Omaha or Charlotte.

If you are mobile or even slightly mobile, make a list of places you are willing to relocate to and then pursue those roles. If you're willing to travel internationally, even better. Most of the limiting factors that make you say "oh, I'd never want to live there" can be assuaged by saying, ".. unless I was making enough money and it wasn't going to be forever."

The combination of willingness to travel and experience/skills in something really esoteric is a rare-enough combination that you'll always have a good job, even in a recession, and often you'll have your choice of excellent jobs.

Like your point, this definitely applies for plumbers, too; it's really hard to do highly paid plumbing gigs in Tokyo or NYC over Zoom.

Remember, unlike most startups, with consulting or jobs, you only have to sell one product: you. So, how unusual the need is doesn't matter. There might be only one job in the world for that. What matters is that you are one of the very few people who can fill that need. When it comes to consulting, niche thyself.

Maybe. I've known people like you describe who were legitimate experts in various aspects of some legacy system or another. And they probably had a pretty good gig--until they didn't. Mainframes probably have more staying power (and are still being developed) but I'm not sure that starting out I would be deliberately optimizing for something like this.

Then, learn about mainframes since most of the COBOL in the wild is running on z/OS or the like. IBM use to offer a free Mainframe course. You would also want to learn JCL, REXX, and a few other mainframe related tools.

The apps are no different then most things now (inventory, accounting, etc.) is is the legacy processes that will most people that biggest problems.

And checkout a YouTube Channel by moshix. Lots of great mainframe info there.

That would get you started on the path.

Though there are things what show its Batch background, I used it on z/OS and the fact that the application did none of its own IO was weird for me.

I didn't mind the language itself, but the application I worked on was inventory related, which was mind-numbingly boring.

https://www.reddit.com/r/learnprogramming/comments/g5zvpa/ps...

Can you run an AS400 under emulation?? Wouldn't you be developing under a regular IDE with modern tooling [, testing under emulation?] and then transferring to production just like you might with any other system?

On the question of whether it's worth it financially, presumably demand will increase--are people retiring faster than the systems they support or vice versa?

There have been some other recent threads on similar subs from people who actually tried to make the jump to a COBOL role in the past year and the social aspects were brought up again and again, on top of the technical issues ... I can dig a few up if people are at all skeptical.

We try to cultivate a mentor culture. We have internal mentorship, college internships and organized internal cross-training. You can even do extended cross-training in other teams and try out new jobs (within certain limits). And the fact of the matter is we're terrible at it; should be more organized, easier to access, have more objective outcomes, with even more mentors. I bet an unfortunate fraction of our people don't even know we have formal programs. But very large numbers of folks here want it to work, and keep helping out, keep volunteering. I could pick up the phone right now and probably get a dozen or so greybeards from the mainframe group who would say "sure, I'll show a new kid the ropes".

But you're certainly not an anomaly...there's clearly more people who would say "screw 'em...I got mine" than consider helping someone down the ladder.

And also, I've noticed my desire to mentor has (slowly) gone down over time. I'm trying to avoid ageism and certainly not assume that seasoned COBOL devs are less eager to mentor than junior devs, and I hope I'm clear in that I'm projecting what is something of a personal limitation onto my future self.

It doesn't cover COBOL in great depth but does touch on various pieces of the zOS ecosystem and gives you some access to a real mainframe.

There's also this COBOL course: https://github.com/openmainframeproject/cobol-programming-co...

I haven't tried the later and I'm not entirely clear on how you get access to a mainframe environment for it.

That said, I will N-th the caveat that knowing COBOL isn't the job/hard part; it's knowing the extensive ecosystem that COBOL orchestrates.

[1] https://catalog.columbusstate.edu/academic-units/business/co...

My first job out of college - around '94 or so - was working for an accounting software company that sold an accounting package written entirely in RM Cobol for DOS. The entire UI and the backend were all written in Cobol. Poking around a bit, it does look like GnuCobol (https://gnucobol.sourceforge.io/doc/gnucobol.html) allows for some screen I/O… so you could put something together on your own machine.

We used Acucobol, and yes, everything was in Cobol. Acucobol had the SCREEN SECTION and you could put up nice text UI forms on terminals. I did a lot of cool things with cursor-point-and-click menu systems, etc.

Once ported to Windows, and Acucobol's GUI controls, you couldn't tell the difference between a VB6 program and our Cobol programs. All native Windows controls.

There are a few issues with this idea. One is that there is some new Cobol code being written where necessary, but the big firms are trying to get rid of these people. The companies still with a lot of Cobol do want to get off of it, and while this is probably a 20-40 year project, this is not a growing industry, which I think is risky. There are a lot of cobol devs being trained up by the contracting services, which are used by the types of places that still use cobol, so I don't think salaries will ever compete with just being a developer in tech. There is a ton of bureaucracy in the orgs that use cobol, and especially around mainframes in those orgs, so that drives a lot of developers away. Since Cobol devs are often supporting 1-5 systems that they are the only ones that know how they work, and cobol mainframe jobs are typically batch processes, expect to be woken up pretty often in the middle of the night as you are supporting flaky 20 year old code that breaks often, the cobol devs I work with were all doing middle of the night work 1-2 weeks a month.

Even if Cobol salary is great I don't think its worth it. The only point I could see it would be good is as a consultant that specializes in moving off of Cobol. I think a Consultant that could sell to these banks that you know how to migrate systems off of Cobol / JCL / DB2 / Sybase / Oracle -> Java / C# / Postgresql, Now that is where the money would be.

https://github.com/victorqribeiro/perceptronCobol

[1] http://www.hercules-390.org/

Tell that to all the people in outsourcing Firms (e.g. Infosys) who end up coming to the US from India to work on COBOL Mainframes as contractors. The large companies hiring those outsourcing companies are doing that because they don't want to pay top dollar for a COBOL devs. I don't think they even want to deal with evaluating and hiring COBOL Devs.

I know somebody who was in that situation. Was paid decently, but nothing special you couldn't get from any other Dev job.

(I regret not taking it when I was an undergraduate. That, screenwriting with the guy who wrote snakes on a plane, and a creative nonfiction class are things I'll be forever regretful I skipped to take infosec courses that simply certified things I'd known since before I had finished puberty.)

We think COBOL will still be around 30 years from now, so we're training college grads.

No cobol experience? I don't think it will be a problem if you already know another language well.

https://www.indeed.com/jobs?q=Healthcare%20Mainframe%20Cobol...

https://www.elys.com/blog/mumps-the-arcane-database-language...

EPIC has about 1/3 US market share, and the VA--the largest healthcare system in the country--has its homegrown VistA CPRS. So MUMPS isn't going anywhere :)

I work with these industries, not directly for them, and seemingly the people that work in them seem more miserable than those in other industries. You are dealing with large amounts of regulations and inner organization bureaucracy. Coding, unless you're a contractor is a tiny part of the job, and process is a huge part of the job.

Check it out: https://github.com/openmainframeproject/cobol-programming-co...

Even if you got a job paying in the 90th percentile in 2010, you'd have a pretty average salary now if you received the standard big corp 2% annual raise given that market adjustments have been in the 8-12% pa range.

http://opencobol.add1tocobol.com/gnucobol/

Note that web page is truly massive, it may take some time to load completely.

Is this a general thing or just for @unsupp0rted?

COBOL or FORTRAN or older languages might be okay if you want to specifically take advantage of that niche, but won't make you quite as hireable everywhere else.

Heh, I recall the most recent Stack Overflow Developer Survey list MATLAB as one of the most hated languages: https://survey.stackoverflow.co/2022/#technology-most-loved-...

Loved: 19.16%

Dreaded: 80.84%

That's not to say that it doesn't have a place or anything, it was just interesting to behold such a clear trend.

Also: Matlab OO is hellishly slow, like having to go on a 5-hour plane trip and mistaking the Ambien you planned to take for a Ritalin.