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.
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?
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.
Unlike what recurring posts on HN would have you believe, it's also not the way to a high paying job, either.