Ask HN: How do I learn real-world COBOL? | Hacker News Reader

Ask HN: How do I learn real-world COBOL?

108 pointsunsupp0rted143 comments

COBOL devs are a specialized niche these days and they get paid accordingly.

I can learn COBOL from a book in general terms, but where would I practice with real-world legacy COBOL systems?

It's not as though I can do a COBOL side-project to learn... or can I?

How does one go about learning COBOL in 2022 (from "scratch", while already being a working dev) in order to niche down as a COBOL specialist dev?

View on HN

> COBOL devs are a specialized niche these days and they get paid accordingly.

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!

Of course the COBOL community is on Usenet. It's so obvious in retrospect.

Yes. COBOL and Usenet are both simple tools that just work and are unlikely to be used by Facebook.

With the difference that COBOL is clunky and unpleasant while Usenet works very well and it's lightweight.

COBOL does well at what it is designed to do. Don't write an operating system in COBOL. Don't write business logic in Assembly Language or C.

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.

>20+ years of experience, often in one specific system

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?

It's COBOL in the sense that any manager in charge of hiring will be looking for someone who 'knows COBOL' and have no idea about what's actually valuable.

What is “well paid” if you don’t mind? Any range you can provide?

This question needs a hard numbers answer.

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.

Anything resembling senior developer salaries.

So essentially not worth the pain if you can get the same salary in a more modern language & environment?

Exactly

Which is what? $120K/yr? $350k/yr?

I'm not in the US. But I've seen well below that in the states.

> the well paid COBOL devs are those with 20+ years of experience, often in one specific system...

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

Start from here: http://www.hercules-390.org/

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.

If you are starting from zero COBOL experience, a mainframe environment may be too big of a learning curve.

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.

An Apple II emulator, such as AppleWin (free, Windows) or Virtual][ ($, MacOS), that supports the Microsoft SoftCard will let you run CP/M software. Microsoft's COBOL compiler is easily available from various Apple and CP/M archives. CP/M itself is a little bit of a learning curve, but at least most everything is free, depending on your platform. There are probably Linux options as well for Apple emulation.

If you want to use CP/M on macOS, you can skip the Apple ][ emulation, and go straight to Thomas Harte's program CP/M for OS X.

I've never been able to figure out how to open a file by passing the filename as an argument to the program you're opening. Apparently there's no ccp.com available. It's fine if you're using WordStar, which lets you view the files in the current directory; impossible if you don't have a menu interface to open a file.

> a mainframe environment may be too big of a learning curve

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.

In my experience, a cliff is exactly what makes you learn fast and deep.

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

You think that those people are getting paid the big bucks because they know COBOL, but the reality is that they are getting paid the big bucks because they have decades of experience with all the legacy systems that surround that COBOL.

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

The old pros are continuing to age out and retire or die. Places with COBOL systems want to keep their applications limping along instead of replacing them. The shortage of devs is only going to get worse. Remember when lock down started and some government systems built on COBOL started straining under the load? Rather than being dismissive, I'd encourage those with any interest at all to try to pick it up. We need folks to maintain it.

> We need folks to maintain it.

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.

as an outsider (and thus potentially ignorant of pitfalls): I'm a big fan of the strategy to add transpilers to modern languages so that we can start writing new code in them, have them output COBOL, and then eventually have enough of the codebase written in the new lang to swap over to it instead.

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.

The example link goes COBOL->Elixir.

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.

This again focuses on the language rather than the environment. The real issue is all the legacy integrations, and the runtime environment, not the language. A transpiler is solving the easiest part while leaving all the difficult problems unaddressed.

The big issue is that for considerable portion of extant COBOL software, you have to deal with entrenched runtime environment. Purely batch processing COBOL might be easier to move to newer languages... And possibly was already picked for rewrite.

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.

A transpiler/compatibility layer is usually fine, but what you (probably) want instead is a IBM VSAM, IBM JCL, and IBM CICS transpiler/compatibility layer instead - COBOL by itself is very simple and we have working compilers for it already; JCL, VSAM and CICS however, not - that's where the real complex, distributed and hard to reason about parts are.

>running critical payments infrastructure

Please tell me its not a payroll company.

No, it's one of the largest credit card processors in the country.

I'm not sure if that makes me feel better.

I do remember that, and as I pointed out in the thread at the time, New Jersey was asking for volunteers: https://www.cnbc.com/2020/04/06/new-jersey-seeks-cobol-progr...

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.

Banks. Period.

I don't work with COBOL but.I had my fair share of old legacy codebases. I sometimes think about how this crappy codebase first started out. Somebody somewhere had to write the first line of code. Was it exciting for them? Was it a sunny day? What did their office look like? Then I look at the codebase again and all this sentimentalism vanishes.

Working on incredibly boring retail banking systems which are a maintenance nightmare. If you want to work in a bank you'd get paid more working on front office software at an investment bank.

Exactly! You will never learn anything about JCL from a COBOL textbook. Heck, I'm not sure a JCL textbook (if they exist?) would be of much help either. When I went to college I was in the last group of students whose client/server classes were all mainframe based. We had a class where JCL was taught and a valid answer for "Why is JCL syntax so irregular?" on the exams was: "Because it was invented in Berkeley in the 1960s and everyone was on drugs."

The truth about JCL is actually worse than "they were on drugs".

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.

There was a ancient saying that new JCL is never written, just copied and modified until it works, because no one understands the entirely of it.

I took an IBM mainframe intro course on Coursera and it was pretty good. I learned how to use the editor and menu thing. It was very out of my windows/linux/PC experience.

> the editor

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.

Here's a look at mainframe arcana from the perspective of someone with training only on POSIX/Windows era systems -- COBOL was the easy part. Figuring out how to format the program text and submit it to the compiler took... quite some time.

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

This is true, but the niche should be a dev who knows COBOL IRL enough to translate to something newer. Much of the COBOL I've seen would be trivial to rewrite, just nobody wants to tackle it. A person who 1) Can read cobol 2) can communicate well with stakeholders and 3) can translate to NodeJS/Python/.NET should be able to fit this niche pretty well.

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.

Some killers here are the data model and the unknown edge cases. And the size.

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.

Some banks tried to jump on the Java bandwagon when it was the hyped up thing of the moment and now many are going back to COBOL.

> 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.

> Some banks tried to jump on the Java bandwagon when it was the hyped up thing of the moment and now many are going back to COBOL.

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

Hah, well, right. I just meant from a longevity standpoint. What stack can I use today that is and will continue to be well supported for 30+ years?

I've converted some legacy apps into, not a joke, PHP3. In like 2006-8. So, PHP3 still works this many years later (in VMs). Currently working to migrate to PHP7.

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.

Come on, are you serious? COBOL is still being used exactly because it does not have a high-churn ecosystem. Same for C and C++.

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

C, C++, probably Rust, various other relatively boring languages.

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

> What stack do I pick today that will still be running in 30 years?

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 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-...

Where did I suggest rewriting things from scratch?

What makes you think HTML/JS/Node will be anything like it is today 30 years from now?

they are good enough

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

the few I've seen, COBOL legacy is its own kind. It meshes decades of users, practices, tools and paradigms. We've been shown code that blend old original code with 3GL crude code generator with 4GL custom COBOL transpiled DSLs with monkey patching. It was really not pretty (to stay polite).

My last project as an intern was to rewrite an old batch processed COBOL app into a simple webform in C#/ASP.Net. The COBOL app was nothing special, really. From what I recall, it was around 65 pages printed. Took me a while to comprehend what was going on, but the first 80% or so was basically just hard-coded rules to take action on based upon user input. Things like when "B", generate "X" & "Y". When "A", generate "X", "Y" & "Z" sort of thing. Nothing fancy, at all. Once I figured out what was going on, I basically just ran the COBOL through some regexs, transformed into an XML doc (don't judge me - it was early 2000s) and wrote the rules engine in maybe one or two screenfuls of C#.

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.

NEXT SENTENCE (not "MOVE NEXT SENTENCE") is sort of equivalent to "continue" in modern languages.

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.

You never ran into an ALTER ?

> COBOL transpiled DSLs

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.

I've nothing against cobol, but I think it's worth there, because of the gap with a python like lang (IBM made one) and cobol. Coffeescript to es5 wasn't too hard to guess.

Like the nightmare language IBM OS DDL? (data definition language) I recall you have specify the physical layout of data files on disk. In UNIX this info is embedded in the file system and generally not needed to run a program.

> In UNIX this info is embedded in the file system and generally not needed to run a program.

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.

"I'm gonna learn C and start an embedded firmware job!"

You got to start somewhere

Yeah, this is what I learned too from working at a big government pension office

aye decades of COBOl here though I did it upon the wrong non-IBM platform, RIP ICL and Honeywell

Yeah, I programmed in COBOL for 15 years on Unix systems... so I don't have any mainframe experience... I'm pretty good with the actual COBOL code, but as people have said, that's only a piece of it. Working with the environment, such as IBM mainframes, is a big piece. Which is sort of odd, because COBOL was supposed to be "common"...

Presumably these platforms have also lived on though. I think I remember reading about a Fujitsu contract to maintain a big U.K. government ICL derived system?

There isn't the work on the market for any of those and from my experience of working with on their contracts, they will all be tuped existing staff.

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

Interesting - thanks. Won’t get fixed now. I’m guessing all emulated and running on x64 by now.

Long live EXEC 8.

this is the best answer.

As stated elsewhere, learning COBOL really isn't that hard. It's a different paradigm than you are likely used to but once that clicks you can be relatively proficient in basic COBOL in a few weeks.

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.

Agreed on most of that, but this is not always right: "cursing your predecessor for not having that foresight to realize that a number might grow beyond 999"

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...

> The hell and chaos of real world legacy COBOL all consuming.

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...

I work at a place that uses an extensive amount of JCL, COBOL, REX, MK4, VSAM, DB2, and more, and I would say that learning the language is only a small portion of learning the system, batch processing and the database. Learning COBOL without learning how the mainframe works in its entirety is leaving out the major portion of what the language is used for. It would be like using a C64 your whole life and then learning Java from a book, but not having a system to apply it to. The leap is just too great without immersing yourself in ISPF and all the associated proprietary software your shop.

Not that salary alone should stop you, but if you look on glassdoor for the range of salaries of COBOL devs vs react or Go, the median is lower and the ceiling is also lower.

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

Yeah, I don't think they're "paid accordingly" - if you're looking for money, just learn Java, it's easier to find resources on and it pays WAY better.

> just learn java

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

Do you have some good resources? I have some industry experience with Java, but not enough.

My understanding has been, if you're highly experienced, you can make some serious money as a consultant, without that you can also get stuck as a code-monkey at crap salaries.

You can say this about almost any technology. You can say this about a sufficiently skilled plumber.

Also a willingness to consult (be a contractor) and/or relocate to where the best jobs are. Not everything is Zoom-able. Programming, in theory, can be done anywhere, but in practice that's not true, especially for old-school jobs where skillfully interacting in the (technical, people, etc) environment can be more than 50% of the actual job.

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.

>The combination of willingness to travel and experience/skills in something really esoteric

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.

Funny you use that analogy, people seem to similarly beleive plumbing is a fast track to big money.

Selection bias.

Have spent a couple years about 20 years ago dealing with a COBOL applications, I can tell you. Pick up COBOL (GNUCobol is fine) and a book. It isn't that hard of a language to pick up.

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.

I'd argue it's quite an easy language to learn, even.

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.

Yea, it has it quirks (every language does) and does show it's age in things.

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

It’s honestly not worth your time to learn this for the money.

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

https://old.reddit.com/r/learnprogramming/comments/g5zvpa/ps... - is probably the most succinct from that thread. Your challenge isn't just learning Cobol - that's relatively simple. It's all the surrounding infrastructure that is also very different - different OS, different file system, different database, front-end is 80x24 green and then you get into source control, build and devops which will all be different.

Either side of the millennium my job involved daily use of a terminal interface (on WinNT IIRC) to a green-screen, to me it was just like using pico (which was supersedes by nano) through konsole. But I was just a user, and grew up with monochrome VDUs.

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's also an issue of community/people you'd work with. (Fair or not) there's a strong perception that the current COBOL devs are people that are close to retirement and not exactly eager to take a junior dev under their wing and give the sort of mentorship that one can't get from textbooks and hobby projects. I'm not a COBOL dev or part of the community at all, but I doubt it compares at all to the language-based communities that people around here are more familiar with.

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.

I have found on the occasions I've had to travel to mainframe-world, our COBOL devs (we have many) are very interested in mentoring younger people, and have had some success recruiting them. They understand extremely well that they have a lot to pass on and limited time to do it. I'm sure not all shops are like that (like any insular tech community), but there's probably some selection bias around folks who's response is to run to a sub to complain.

I don't doubt there's some people like this, but if I cut my teeth on mainframes 2-3 decades ago and was nearing retirement, I'm not sure I'd have the patience needed to be a good mentor. (I'm sure I *should*, but as a personal limitation I might not, and I'm probably not alone.)

That's...sad?

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.

I've never worked somewhere in which mentorship was formalized *and* something for which there was a clear relationship to promotion. Not saying that the only way to get me more into it is by paying me or threatening compensation, but when push comes to shove the things that aren't tied to promotions are the first to go (especially in management).

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.

Yes, if the only metric that motivates you is "will this get me more money/promotion", you will certainly look down your nose at people who help others succeed and create fictions like 'no one' in their right mind would do that. My experience has been that there are numerous (though clearly not the majority) people who look at the world differently.

That's not what motivates me, thanks, but it's clearly what motivates the industry

I know two people who started as COBOL devs, not sure what they're doing right now but they're both in their 40s. They were part of a big bank recruitment in the noughties.

IBM offers a free set of courses here: https://ibmzxplore.influitive.com. I played around with it a few months ago. As far as I know it's still available.

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.

I think you’d have to actively seek a job somewhere that has running COBOL and then express interest in picking it up. They’d probably be happy to have you, but you wouldn’t be making the big bucks. That would have to wait until you had a decade of experience and then venture out on your own as a consultant or get hired by a specialized outsourcing firm.

TL;DR; find a way to work in a mainframe environment. I think this is true of a lot of things, but starting in 2022, it's definitely true for learning cobol. The thing is, cobol is not just a programming language. Living and working in a mainframe environment is it's own whole thing. There is so much you'll have to learn. It's like the difference between linux and windows, but I'd argue is easily x2 to x5 as jarring. Just learning ebcdic instead of ascii is a thing. And navigating a green screen is as foreign to a modern pc user as, say, going from being a programmer in a high level language (like say java or c#) to using assembly language. It's not that you can't learn it, but it's that your whole brain has to be tilted to the side just to understand what's going on. A mainframe is a completely different world from modern pcs. The cobol programming language is 1/10th of it.

There are a number of schools that have mainframe oriented CS programs if you're really serious and have the time/money. Columbus State University has one created in partnership with IBM[1]. They apparently have a pretty extensive corporate outreach program and the folks I've talked to who were in the program were set up post graduation job-wise.

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...

> It's not as though I can do a COBOL side-project to learn... or can I?

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.

I'm a little older, but similar. My first professional job was in 1985, programming in Cobol on Unix systems, on an accounting package. MS-DOS and IBM PC's were just becoming important, and we did later port to DOS, then Windows.

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.

I did this a few years ago to support an HP3000 in a new job. Spent a year working with COBOL enough to get semi proficient and feel confident running and editing programs. We eventually turned the system down in favor of web+SQL and I'll likely never COBOL again, but the truth is COBOL is a pretty straightforward and fun language to work with if you're not already stuck in the C/C++ mode of thinking. Its pretty easy to read and decipher.

I worked 5 years at a large financial services firm with several $T in assets, and as such I have worked with Cobol Developers, though I have not worked with Cobol much directly. They had it splits between Cobol developers on one hand and then the AWS/Java/Javascript developers on the other.

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.

I don't know if this could be considered "learning" in the sense that you mean, but I chose code that I wrote in a familiar language and re-wrote it in Cobol. It was fun and I end up learning a lot.

https://github.com/victorqribeiro/perceptronCobol

You could learn some mainframe stuff using the Hercules emulator[1], but you'd have to find some z/OS installation media somewhere, and I'm not sure if that might infringe copyright or something. Also, JCL is absolutely horrible IMO.

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

I went to a computer conference in the mid 80’s for my first job after college - where COBOL, IBM/360 assembly language and FORTRAN were required CsC courses - and the international attendees used COBOL as a common speaking language. So conversations like IF HUNGRY PERFORM EATING were common. haha.

Depends on your country, but I do know for a fact that if you're in the UK, there are government departments which will teach you modern development practices alongside COBOL, if you're near one of the relevant hubs.

It's not real life but doing COBOL CTF was fun intro https://samsclass.info/129S/COBOL.shtml

>COBOL devs are a specialized niche these days and they get paid accordingly.

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.

Check if the University of Pittsburgh School of Information Science is still offering their course, and if it's offered online if you aren't blessed enough to live in the "Paris of Appalachia".

(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.)

Many industries are still running on COBOL including healthcare.

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...

How about MUMPS (ANSI-M)? Is it still used in healthcare, or did they manage to replace all systems?

MUMPS and derivatives are still the basis for the major EMRs in use today.

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 :)

Is this still up-to-date? Wasn't VISTA replaced by a COTS product by Cerner? And isn't EPIC implemented in Caché and its Object Script (i.e. not in M)?

Looks to me like all of those require experience.

Many do, but some don't. Contractor positions would most likely require experience, but full time positions would include more entry level. They're willing to make the investment to FTE.

The real question you want to ask is "do I want to work for a bank, Healthcare, or government".

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.

A great learning resource for COBOL is the Open Mainframe Project's COBOL Programming Course. The content is self-paced with labs and the best part is you get to do the labs on a real Mainframe.

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

The content is also available in video format on IBM Learning platform. You get to do the labs through the video course as well and earn a badge. You can check that out here: https://learn.ibm.com/course/view.php?id=7552

COBOL is available on many platforms. Health care, Banking, Government and many more. There are many ways to get started with COBOL, pick an emulator/internet site to get some experience with it. If you still are interested get one of the many free accounts on actual hardware/OS and learn the environment.

Do COBOL programmers really get paid that much? I have more than 10 years of experience with COBOL, and I've left it long time ago because I hated the language. But now I wonder where could I find some of those well paid COBOL jobs (and of course - remote)?

Not from the evidence available on glassdoor and whatnot. Which makes sense, if job-hopping is the way to level up one's salary, then getting a job where there's like one or two employers in a region is going to keep your salary at the same level.

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.

The GnuCobol FAQ and How To might be helpful:

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

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

You might get some mileage out of posting on /r/cobol on Reddit. There's a small but somewhat active community of COBOL folks on there.

Related question: what's the modern COBOL, meaning the thing that will require well-paid niche programmers to maintain in 30 years?

I'll hire you if you want to learn COBOL.

"You interest me strangely, sir."

Is this a general thing or just for @unsupp0rted?

Really? I'll learn anything if I can get a remote job doing it.

If you really want to learn COBOL we're are looking for people all the time. You can drop me an e-mail.

Parallel question: what would be better to learn job market wise right now, Cobol, C# or Java?

Honestly, C# and Java are vaguely similar (GC languages, lots of OOP, with some FP sprinkled in, like LINQ/Streams) and some of the more popular frameworks, such as ASP.NET and Spring Boot shouldn't be too hard to pick up - so personally I'd go for both.

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.

FORTRAN is for scientists who use computers to do their science. IMHE, it's not really a language used by generic software engineers, you would be expected to understand how to apply complicated math to some sophisticated problems. The place I worked for had a pipeline to turn PhDs into FORTRAN developers; CS/SE people filled the support roles and mostly wrote C & shell scripts.

Modern Fortran is easy to learn if you have Matlab muscles; there's a few additional concepts to learn because it's a "static" language, but much much easier than, say, Rust.

> if you have Matlab muscles

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.

Matlab has OO concepts that make for much cleaner concepts.

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.

learn universe or any of its flavours (i started out on pick basic at 19, now 34) its not as obscure but niche enough that with time&skill you can find yourself in demand quite readily

Reply on news.ycombinator.com