Introductory-level educational COBOL materials with modern tooling | Hacker News Reader

Introductory-level educational COBOL materials with modern tooling

openmainframeproject.org

71 pointsmooreds24 comments

I have heard that a developer willing to learn COBOL can land a massive salary. Is this actually true? What companies are hiring/looking for people and is there a place to get realistic numbers?

It's always been my understanding that many COBOL applications are highly coupled to some sort of old-school mainframe-type server. So while a programmer can probably pick up the language with enough time, the mainframe knowledge will be much more difficult to acquire. Therefore, I assumed those earning the highest salaries in this space have deep knowledge of both. To those with experience writing enterprise COBOL - is this really the case? Is someone with only COBOL-the-language experience ready to work on real-world COBOL applications at most companies? Or would they need mainframe experience to be competitive enough?

I think you're right about needing both the language part and the mainframe knowledge. When I worked in an enterprise with a heavy mainframe presence, the COBOL was divided into 2 parts: online (3270 and CICS) and nightly batch. All of it was on z/OS (formerly MVS) and largely made use of DB2 and some VSAM. To do anything useful in z/OS you need to be comfortable with JCL (Job Control Language) and it's fairly archaic. Traditional z/OS views files as 'datasets' on secondary storage. There are catalogued and uncatalogued datasets. In old-school MVS, when you create a dataset you have to pre-allocate it by specifying low-level storage slices like number of disk cylinders. This is the perspective of the traditional CKD/ECKD storage. It's probably been smoothed over somewhat over time, but I'd expect there to still be a great many archaic things to wrestle.

Yeah, this is the exact sort of thing I was picturing. So for, say, a recent CS graduate, the common methods of, say manipulating files/data e.g file descriptors, sockets, databases etc, don't seem to really apply within the kind of environment you describe, which makes me question how much knowledge a 'typical' programmer can easily port over to working on real-world COBOL systems or at least how fast said programmer can start making meaningful contributions to the codebase. I'm not sure how much effort any given company looking for COBOL devs would want to invest in teaching new programmers how to work in the environment and are probably preferring people who already understand the mainframe they're using, which would exclude most working developers. Even if the company is willing to teach you, that skillset probably won't be useful at your next job, unless you want to start a career as a COBOL dev.

tl;dr learning COBOL as just a programming language doesn't seem to prepare you for an actual COBOL job in most cases, unless the company is willing to invest in teaching you.

Furthermore, to the degree that someone is making big bucks, they probably also have a wealth of domain and possibly organizational knowledge. Pretty much no one is walking out of a CS degree--which is mostly irrelevant to maintaining generally legacy mainframe systems--plus some COBOL courses and expect to be showered with highly lucrative offers, if indeed someone want to hire them to work on mainframes at all.

You hit the nail on the head, but I'd say that things are more proprietary and thus secret than simply being archaic. For instance some places still use MARK-IV, but build out new features using Cobol. And then there is a whole field of job scheduling language like Jobtrac. It is a vast ecosystem with its own security system language like TOPS which also has it s competitors.

Also, overnight batch processing may not be automated but require an operator initializing each job in the schedule or schedule in the schedule with runsheet instructions. I think dialogs are created with ISPF and software for moving software from test to production, but I'm no expert on the mainframe.

https://en.wikipedia.org/wiki/MARK_IV_(software)

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

The mainframe has a large ecosystem that is needs maintenance and feature additions and the work doesn't pay so bad if you don't mind the system. I know Mainframe DBA's make $110k in Dallas/Austin.

I don't have actual numbers for you, I will say that the work environment at a COBOL gig would be considerably different than you may envision when you think of a life of a programming.

These are legacy systems that need long term maintenance. If you like building cool new things and working in a laid back environment, the salary may not be worth it.

COBOL is used in industries that view IT and software development as cost centers. As such, these departments have been subject to decades of ruthless cuts and offshoring.

So now the chickens have come home to roost, and there's a skill shortage. You'd probably end up at Fiserv, or maybe at a big bank or some gov't agency that'll drop you at the first opportunity. You'd get a decent salary, but not a massive one.

You'd be better off working at a place that views your development effort as something that generates revenue. Rewards tend to be higher. And wherever that ends up being, they almost certainly won't be using COBOL.

I’ve heard it isn’t. From what I’ve heard, the salaries aren’t that outstanding, and the people getting them are being paid for their experience with the environment, not the language.

It's not the knowing cobol that does this, it's the being a domain expert in a complex system that happens to run cobol that does it.

That said it's largely a fake idea yes. "There's a shortage of cobol devs" sounds a lot better than "we spent decades undervaluing, outsourcing, and not supporting mentorship in this critical niche and now we're experiencing the consequences."

Have a look at the offers on Glasdoor. Only slightly above the typical Java Dev salary.

I'd say you've heard very wrong. If your concern is maximizing your income I'd highly recommend not going the mainframe route. The only people commanding SF/NYC gargantuan salaries will be old guard who retired to do contracting and get brought on to un-fuck situations at incredibly high rates under short term contract. IME you're likely to see MAYBE 80-100k as a midlevel COBOL dev as you're competing primarily against offshored pay - I would expect bootcamp front end devs to make as much or more than COBOL devs.

Also as others have insinuated, COBOL itself isn't a challenge (nor PL1 or HLASM or any other language really), it's the zOS/360 mainframe environment, understanding the nuance behind how all these disparate systems work together, being a JCL wizard, knowing all the IBM yellow books off the top of your head from 40 years of working in the industry, understanding how to use IBM IMS db efficiently, etc. Also the entire ecosystem of stuff you might take for granted, like IDEs/debuggers/deployment/etc, are all quite ancient on zOS systems and take years to get proficient in.

My understanding of is that the problem isn't "learning COBOL" it's learning all of the environment that surrounds COBOL, the IBM Z Mainframes, learning JCL and what not.

In fact it seems this is the case with every language, Java was the first language I picked up, I did it through school, I am familiar with syntax and how it works under the hood, yet I don't feel comfortable on Java projects, not because I have any problem with Java it's because I don't know the entire environment around it, there's DI frameworks, finding the magic Spring config to make things work the way you want, etc. As an engineer I don't really have an ability to see what is going on in an application and really trace the code start to finish because there are three or four layers wrapping, abstracting, surrounding, or smothering any code that anyone has actually written on my team.

Same thing with .Net I've tried picking it up since .Net core came out, but it just seems that figuring out how to string all the packages, and dependencies and figuring out how the build tooling works is more effort than the language itself.

Repeat for JS, you can know Node and JS and in this environment that will get you a nickle and a piping hot cup of Jack Squat because you can't just know JS, you need to know JS, and React or Angular, and in order to work with those tools you also need to use Webpack or Babel, and a transpiler and all the tutorials that go "step by step" seem to consist of "install these packages don't ask why just do it and then add 4 lines of code".

The problem isn't nor has it ever been the langauge, so far I've picked up Perl, Python, Java, C#, JS, TS, Ruby, AWK, and a handful of other languages with ease (The only one I've struggled with thus far is LISP) it is the environment that surrounds each of these things, and I only forsee it getting worse as we continue to move things to a higher and higher level, we think we are simplifying but it feels more like we are building a leaning tower on a foundation of sand, where soon coding will become more of a priesthood than anything, where the right incantations will produce a certain effect but no one will really know how or why because no one person knows or understands what the 14 layers of abstraction we are running on do. Which inevitably ends up reinventing the wheel at every layer of the stack as teams try to solve problems within the area they understand not realizing how much easier it would be to solve in another layer, and we'll just end up running around in red robes chanting prayers to the Omnissiah.

01010000 01110010 01100001 01101001 01110011 01100101 00100000 01110100 01101000 01100101 00100000 01101111 01101101 01101101 01101110 01101001 01110011 01110011 01101001 01100001 01101000

When you stop jumping from one language to the next, endlessly searching for an environment that matches your idea of 'purity', and decide instead to invest some serious time and effort into learning a specific platform, and use that knowledge to actually achieve something practical that delivers value to your fellow humans; then you are just beginning to understand what it means to be a software engineer. Every platform has its flaws, every ecosystem has its design mistakes, and yet here we are, thousands upon thousands of people working in an industry that barely existed fifty years ago, creating things which at least some other humans are prepared to spend money on. A subset of those things actually enrich the lives of others in significant ways. Why not choose to be part of that? I suggest for the sake of your own wellbeing, complaining less and learning more. Dig deep into the history of those frameworks and environments that you hate so much, remember Chesterton's Fence and start asking questions about why things are the way they are, what problems have others encountered that needed to be solved. Perhaps when you fully understand what motivated people to put all that crud out there, you could find better and more elegant solutions that will make all of our lives better. Or not. There are plenty of other rewarding ways to spend your days, if software is not for you then perhaps something completely unrelated will be more satisfying.

I'm not upset with it, jaded and cynical maybe, but I still make a decent living and enjoy when I do get to make things, I just would enjoy it more if I spent more time building and creating and less fighting with my tools.

I make it a point to jump from environment to environment to learn to grow, to see the new things and the new tradeoffs, and find out what they play out like.

That being said, I don't need to find or build a better or more elegant solution. I use Emacs ;)

So, there are new systems which are being developed in COBOL?

I hope not. But lots of legacy systems that need maintenance and the occasional new feature?

I remember at the beginning of the pandemic state unemployment systems using COBOL and a lack of qualified developers was blamed as the bottleneck for processing claims. It was all over HN for weeks.

Were the salaries offered by these states also to blame? i.e are there enough qualified developers out there but unwilling to take jobs at the salaries offered by states? I suspect a bit of both - a lot of the old-heads in the space are retiring/dying, reducing the # of qualified developers, but I also suspect states want to cheap-out on hiring those that remain.

A lot of states have replaced their UI mainframe systems through outsourcing to companies such as FAST https://www.fastenterprises.com/. Last I checked, FAST had WA, MT, OR, and a couple of other states. This is in addition to their primary business of state tax systems replacement.

Changes typically require 7 figures, so they require a long lead time that coincides with the state's budget cycle.

Their UI customers, in case anyone is interested (CA, IL, MI, WA, MT).

https://www.fastenterprises.com/solutions/fastui/

Also, the cost of one of these replacement projects is about $80 million over 3 years plus 10-20 million a year maintenance. Averaged over 10 years, this about 2-5 times the cost of the old systems, depending on how you want to count.

No comment about the content itself, but the “modern tooling” part made me expect the website would look modern, but it feels a bit stuffy and outdated.

I think the reference to "modern tooling" is primarily a VSCode reference.

To see just how modern the tooling is, one should look into the procedure for compiling, running, and debugging. Editing the source code is the easy part.

Reply on news.ycombinator.com