COBOL Programming Course | Hacker News Reader

COBOL Programming Course

github.com

103 pointsmarcodiego56 comments

It's Sunday, my dad was a COBOL programmer, sure I'll spend 15 minutes checking it out. The main site link on GitHub is a 404 though [0]. The "getting started" link in the README points to a release notes page and do you have to scroll down to find a PDF [1]. That said, the intro does start with VSCode and a plugin which provides language server support for COBOL (and PL/1!) and a CLI tool (Zowe [2]) for interaction with a Z/OS mainframe. This does seem like a pretty modern and up to date intro. Cool.

I do think this could benefit from someone making a nice "modern language" landing page for it. I remember an April fools joke from 20 years ago promoting COBOL as the hot new web language, maybe it's finally time :)

[0] https://github.com/openmainframeproject/cobol-programming-co...

[1] https://github.com/openmainframeproject/cobol-programming-co...

[2] https://docs.zowe.org/stable/web_help/index.html

> I remember an April fools joke from 20 years ago promoting COBOL as the hot new web language, maybe it's finally time

Cobol on Wheelchair https://github.com/azac/cobol-on-wheelchair

Cobol on Cogs http://www.coboloncogs.org/INDEX.HTM

Somewhat amusing piece of trivia: the author of Cobol on Wheelchair is currently a Polish MP.

Does anyone have confirmation for the old rumour that there is high demand for COBOL engineers because of legacy systems eg in banks? And how does one go about finding these opportunities? I remember once talking to a freelance engineer, he didn't do COBOL but something similar in the sense that a lot of banks had legacy systems with that technology and that people had been saying since the 80's that it'd soon be extinct. He mentioned a (paid) database service which he used to source his clients, he was based in Germany, as were most of his clients. Anyone have an idea what that could be?

I'd totally be down for learning an obscure language and deep-diving into sensitive systems that have been providing value for a long time already. But basic economic logic tells me that there won't be a free lunch there, I mean people pick up new programming languages all the time.

Yes, it's true. My dad works for a large credit card processor that runs a ton of COBOL and they have a really hard time finding people.

The big problem those guys are running into is that they aren't paying anywhere close to market rates for engineers working in more modern stacks. Senior developer pay tops out around $120k last I checked and they've been reliant on cheap offshore contractors for years now to insulate themselves from paying modern dev wages in the US.

Funny thing though, the contracting firms are now notifying these companies that they won't be supplying COBOL developers into the future because there's a lot more money to be made contracting out devs in modern stacks than COBOL. It doesn't get a ton of attention because nobody can see the future, but hearing my dad talk about his company makes me slightly concerned about the future of our digital payments infrastructure.

Yeah its kinda scary. People meme it but so much of the modern world relies on an aging stock of retiree's to come in on contract and do a thing then leave to be sustainable.

It's not the amount of stuff that runs COBOL thats a problem, it's how critical that infrastructure is to human society - I don't think that's an overstatement.

> it's how critical that infrastructure is to human society

Exactly, and the regression horror stories I hear are unbelievable because these codebases are so old.

A while back, a major customer of this processor transmitted a payment reconciliation file that had bad headers in it and brought down the entire reconciliation system (billions of dollars a day flow through this platform). No basic input validation, no escape hatch for corrupted files, nothing. I couldn't believe it when I heard the story. The crazy part was how long it would take to harden the system against bad input like that because a lot of that code was written 20-30 years ago.

People working in modern systems think they know tech debt...

You are right. I started my career in COBOL and I know my way around a mainframe and openvms. When I looked into jobs, they were paying far less than I can make coding in Java, Javascript or C#. They won't pay a decent hourly, so they won't find people. We're out here, but won't take a pay cut.

This is the same discussion as about lacking nurses or whatever "essential workers" which we don't want to pay yet miss them so dearly. And the solution is right there in front of our noses...

Anecdotal of course but I had a taxi driver the other day (small town in north UK) who mentioned, after asking me what I do, that he gets about 1 job a year (from a contact that has reached out because the place can't get anyone else) on COBOL from banks / FS who just need a little thing adding or some bug fixing. He said he basically gets a big holiday every year and some money to put away from it. Hasn't touched any other IT job since early 2000s.

I know its a meme at this point but there is definitely some sort of demand, I think the problem is that, while the stock of people is diminishing, they want battle hardened experts to come in for a few grand a day and do a thing and leave. Not a young developer wanting salary with a big backlog of work.

India was sanctioned in the 90's bythe US (supposedly for being communist leaning) so they couldnt get PC's which meant all they could learn on was mainframes.

In the late 80's early 90's Cobol programmers were being laid off by big companies, as it was all going PC, the COBOL millennium bug stuff was outsourced to Indians because those companies who laid off their staff couldnt get them back.

Its mainly a rumour for the UK and possibly other Western countries.

Tesco bank, TSB all use PC's, the TSB banking system was a rehashed share trading platform which is why they had problems a few years back, seems no one likes old school db transactions.

Tesco is full on in MS's pocket as is most of the NHS systems, and these are all online, when you do your online Tesco shop you connect to the store that will do the delivery because every store has a different product range and no mainframe or server could handle that for the whole country. You your GP surgery systems, regional health trusts, are all online which then gives you an idea of who is behind Wannacry considering the level of spooky surveillance of telecoms here in the UK.

That is how some Indian IT offshoring companies grew big, thanks to those COBOL projects.

Extremely likely but it was a way for other country's to get around US sanctions, because sometimes just sometimes the law is not incredibly vague.

I can tell for a fact that was the case with TCS, thus likely with others as well.

There is absolutely demand. I've been doing cobol for four years and have banks and insurance companies asking me to come in for an interview all the time.

But no remote teams, no companies ready to offer any support for relocation and not a pay making a move worth it until I've built up some savings.

I think the offers I've seen in Scandinavia are 35-40k/month for a dev with some experience, and very slow wage increases.

It's true there is a lot of demand, but it's not true that it pays a ton. The devs returning from retirement with 20 years of experience with the specific systems can, and do, charge a lot though.

What is the day to day like?

Is it codebase migration to newer stack? Adding features in Cobol? Documentation for the next generation of Cobol developers maybe?

I think Cobol development/maintenance work should exclusively done by contractors/agencies as opposed to hiring employees. Contracting is perfect as older devs are more suited to work part time or as sub-contractors and banks don't need to have a greater responsibilty of an employee whose skillset is what they are trying to abolish.

I've worked with developing new features and maintaining existing code. Never worked on migrating away from cobol.

I'm confused, is 40k/month is not paying a ton? That's half a million a year of whatever denomination.

https://www.xe.com/currencyconverter/

They didn't specify the currency or the country. That's why I asked.

I did forget to specify. It's what I've seen in DKK and SEK. Not USD.

Might be in SEK or NOK which is about a tenth the value of USD.

If it’s kroner (Norway) that’s $51,000 a year. So maybe not that either.

I assume this is 40k Swedish Kroners which is about 4k USD per month.

You should definitely be able to negotiate more than 35-40k/month, at least in any of the larger Swedish cities. Next time you interview try asking for double that and gauge the reaction, it might be more achievable than you think.

What I've always wondered about this is what kind of experience companies hiring COBOL programmers are looking for. Anyone can learn COBOL the language, but it seems like the real issue with hiring COBOL devs is that you need to have experience working with mainframe technologies that are basically impossible to get any experience with outside of already having a job doing it. Kind of like how anyone can learn $some_other_language but what really matters for getting work done tends to be familiarity with libraries and stuff like that.

If it were as easy as learning COBOL for free on my own time I would do it in a heartbeat. Can't be worse than having a dead-end IT support job.

> Anyone can learn COBOL the language, but it seems like the real issue with hiring COBOL devs is that you need to have experience working with mainframe technologies that are basically impossible to get any experience with outside of already having a job doing it.

Most (IME, and I suspect generally) of the places hiring COBOL devs already have COBOL devs (and probably non-developer mainframe ops folks) doing those other tasks already, and if someone is both a half-competent programmer and knows COBOL-the-language, having them pick up the other stuff through OJT is probably tolerable.

There is definitely demand for ABAP, which is influenced by COBOL, and has a similar looking syntax.

https://en.wikipedia.org/wiki/ABAP

I personally had to write a small fragment of PL/SQL last month that interfaced with some COBOL that manipulated Rdb (new development required on that side). We are down a few developers in that arena.

Yes, it's true. My mother was a COBOL programmer for nearly 30 years. She retired in 2012 and quickly got bored. I convinced her to consider contract work, to ask for the sky - short-term contract, 100% remote, lots of money, etc. She got a ton of offers. However, she dismissed them all. The process convinced her that she was really retired, and was never, ever going back to work, no matter how much money was involved.

I've discussed it on HN previously, but out of college I took a position doing development on IBM zOS mainframes writing HLASM and COBOL. When I left that company after two years (around 2014), I was making roughly 75k. The salary bands I saw capped at about 120k. I moved to NYC and joined an A stage startup and instantly was making 110k as a junior working on a rails stack with zero experience. In the following years I'd proceed to continue getting substantial compensation increases, where everyone I know in mainframe land still appears capped ~100-120k.

So, frankly speaking, there is plenty of demand but it does not pay anywhere close to market rate for US based engineers.

This project made the rounds a couple of years (months?) ago. Always accompanied by mentions of companies having a hard time hiring engineers to work on COBOL codebases. I've never had the luck of stumbling on one of these. Maybe because I'm not based in the US or just didn't look hard enough. It'd certainly be cool to take a peek at that code.

About 20+ years ago a friend of mine and I had just started a company in Denmark, and we got a call from a bank that wanted to know if we had any experts in 'protocol' design, and if we had anyone that knew COBOL. These were not our specialties but at least have had one contact.

Banks, insurance companies, in-house IT at large corps and govs is where you will still find COBOL.

By the way if you are already a reasonably good programmer you can pick up COBOL in a few weeks. It's a very straightforward language. Getting familiar with how things are done on a mainframe will take longer.

My friend is a manager at a big insurance company. They have a bunch of legacy stuff in COBOL.

Agreed on everything you say, except I still find it curious why these seasonal "let's learn COBOL" posts find a place here on HN.

I mean, yes, there's a challenge in navigating boring legacy COBOL banking systems, which follow no conventions, were created before code versioning was a thing, or best practices for that matter. Yes, it's challenging and therefore of interest to hackers, but still...

... striking my fingers with a hammer is similarly interesting and challenging, but why would I want to do it?

I would not be so sure on the "follow no conventions, created before code versioning was a thing"

COBOL shops in my (admittedly limited experience in the early 1990s) had conventions, standard skeleton code for various things (referred to as copybooks) and source code control of a sort (very centralized of course, since everything was centralized). They definitely had separated "regions" for dev, test, and production where I worked, and a process for moving code changes to production. In my experience (as a staff consultant with a major firm), if they had consultants building systems, they certainly had a defined methodology, as consulting firms love that.

I'll grant that there may have been a wide range of variance on this sort of thing. Just as there is today in many shops.

I'm also not trying to sell anyone on the idea. Going back to COBOL would be about the last thing I'd want to do personally, even if there were good money in it.

Interesting. That wasn't my experience working at a bank, or my dad's, but it was the same bank ;)

Nah, your intuition is right: there are not that many jobs for COBOL (not outside boring legacy maintenance jobs for banking systems).

Unlike what recurring posts on HN would have you believe, it's also not the way to a high paying job, either.

I worked with a guy who had the systems manual for a US nuclear missile facility. (I have no idea how he got his hands on it.) It had a bunch of COBOL in it.

I interviewed as a COBOL programmmer.

The place had given up hiring actual COBOL programmers, and instead hired pure computer science folks and Java programmers.

That combo seemed to work fine.

Interesting. I'd expect Java programmers to be the least likely to be willing to learn a different language:

Why?

Java is a starting point for many programmers, especially because there was a time were every "coding school" was a Java shop. But programmers naturally migrate from that to other waters: some to Scala or Kotlin, others shift gears and go to Python, others choose Golang.

Java has a special affinity to COBOL, if only because Java is/was widespread in "enterprise" systems. A common joke was that Java was the successor of COBOL!

There was a local culture of assuming Java programmers could learn any language.

Lots of positions would say “seeking Java programmers” but not involve actual Java.

I think this was because there was a surplus of Java people.

Java and COBOL share some common principles. The languages aren't the point, the platform are. They both run on high performance / reliable virtual machines, allowing a superior scalability, reliability and long term compatibility to what could be achieved with more coupled approaches.

Likewise, running COBOL tied to an x86 instance could be feasible but would be missing the point entirely.

You could more or less consider a JEE application server as a software implementation of a mainframe. Java AS (Websphere, Weblogic, JBoss...) are essentially what killed the mainframe and midrange (IBM i / AS/400) in the enterprise. So yeah, Java/JEE, COBOL, RPG: different languages, same goals under the hood.

The COBOL/Java jobs would often ask for JEE experience.

I had fun a few years ago learning a little bit of COBOL and wish this had been around then because you never know if any of the documentation is relevant to modern-ish COBOL. Feel free to repurpose this version of tic tac toe for learning https://github.com/ShaunLawrie/TicTacTOBOL

There should be a section devoted to JCL (Job Control Language). It is arcane and difficult but is the secret sauce that makes IBM COBOL so powerful on mainframes. I looked at the courses briefly and didn't see it mentioned.

Even back in the day, people who could write JCL from scratch were few. Most people took the JCL from a similar job and modified it. At least that was my experience.

And VSAM?

Can you point to any JCL resources on the web ?

Late 70s, IBM mainframe at college, running FORTRAN, PL/1, and PL/C. The guys that knew the secret sauce hung out in the keypunch room and once in a while applied their magic. SYSIN DD *, and all that.

LEARNING COBOL IS VERY GOOD IF YOU WANNA INFILTRATE AND HACK LEGACY SYSTEMS.

I think you meant:

    IDENTIFICATION SECTION.
    AUTHOR ULTIMAPE.
    PROGRAM DIVISION.
    CODE STARTS ANY MINUTE NOW.
    YEAH, REALLY.
    LEARN COBOL GIVING HACKING RESULTING IN INFILTRATION.
    CODE ENDS HERE.
    REALLY.
    THE END.

Is there something equivalent for PowerHouse in the v7 era? Other than the pdf manuals which are more like man pages than learning ressources?

How about a COBOL:Python cross compiler?

Don't do this to yourself in 2022

Reply on news.ycombinator.com