[jmt_]

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?

[neverartful]

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.

[guessbest]

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.

[jmt_]

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.

[ghaff]

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.