The technology stack you choose early on is pretty vital to your career growth. A common way of growing your salary early on is to switch jobs every few years. And to do that successfully, you'll want to have a valuable skill-set that hiring managers are looking for.
For all the talk around here about "fundamentals" being what makes you employable, my experience shows that is not the case. For example, my company doesn't interview candidates without Javascript on their resume because they want people who know and have worked with it. I think it's a dumb policy, but I have no control to change it.
Being in The Enterprise, I find it quite frustrating dealing with the new shiny every few years when there's rarely objective analysis behind being made to do so.
Beyond that, IBM has a ton of educational resources you could leverage. At one time they had a program where you could get an account on a mainframe, but I don't know if they do that any more.
Udemy has some mainframe/Cobol tracks. I assume other on-line training does as well.
There are a number of colleges that have mainframe focused degree tracks (Columbus State University has one). These days, you could probably find one that does it on-line.
You absolutely shouldn't learn COBOL before knowing which job you're aiming for. COBOL isn't an interesting or particularly useful language to learn.
Otherwise you're "putting the cart before the horse", so to speak. Plus listing COBOL in your resume can have a detrimental effect in future job interviews, at least at some companies.
I started coding when I was 8, I am 32 now, and in my government-issued employer list, I had zero employers.
My dad knows COBOL and MUMPS, and kept talking about how horrible they are... but maybe I can get a job if I try these.
With a portfolio like that, you might want to look at why you can't get a job. You sound capable enough on the technical front, so there must be something else that's preventing you from advancing your career.
Not sure if this helps, but could also lead into working close/near with mainframes and COBOL.
It's what value you can provide with those that counts.
One of my earlier companies started with a policy against hiring folks who just knew PHP, even though that was our main language. We wanted folks who knew SQL, some JS, maybe some C or something to prove they were well-rounded and could think about tech as a whole.
We dropped that policy when folks started coming in with _just_ Ruby on Rails under their belt. They were destroying our project-based interview and blasting out projects in weeks that typically took us months. And we found that we could easily teach them the SQL they needed when they needed it.
I'm not saying it's _just that easy_ but if a dev hits my interview process and shows they can understand my customer's needs and build out a solution to those needs quickly, I _very much_ want to give them a job.
Do you mind sharing where you live? That’s such an odd concept to me.