Hacker News Reader

Comment by freedomben | Hacker News Reader

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?

View on HN

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

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.

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

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.

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.

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

Reply on news.ycombinator.com