Also, COBOL work is kinda crap. Debugging 20-year-old Java code sucks, but a 40-year-old COBOL project, with source code backed up to 5-inch floppy disks - forget about it. (I just watched the trailer for 'The Many Saints of Newark'. LOL)
They don't have enough work to train them on and whatever they have is actually critical enough to need someone experienced.
My partner was hired to be a COBOL programmer right out of college in 2004 & trained to work on AS/400s.
The problem was that everything was a small part of a big project, but you got no experience building a big project over its lifetime to see how it should be done. And on top of it, a lot of things which were "the right way" in 1991 wasn't so great in 2005. So a lot of work was actually bringing the existing work to code before you could do the tiny bit of work which is actually needed.
The pays for COBOL do not even look that compelling and you are walking down a dead end when these systems finally modernize. I wouldn't touch cobol for anything short of $300k and the promise of enough work that I could retire within a few years.
I guess there just aren't enough takers.
The old -- and likely not so bad -- advice if you'd like to learn how to use a Mainframe is: Get access to a one, get a copy of latest Red Book [2], and start playing around :)
[1]: https://www.ibm.com/it-infrastructure/z/education/zxplore (this isn't the program I went through, but my old bookmark now redirects here)
[2]: https://www.redbooks.ibm.com/abstracts/sg248852.html (IBMs mainframe Technical Guides traditionally have a red cover)