Shortage of COBOL developers in insurance and banks

In any other computer your small number of general purpose CPUs have to handle all the business / application logic plus disk IO, network IO, cryptography, system housekeeping, etc. On a mainframe all those other things are offloaded to specialized coprocessors and the actual business logic gets nearly 100% of the cycles on hundreds of special purpose high frequency water cooled business logic CPUs running at 5+GHz.

Also any component can fail and be replaced without downtime or lost transactions. CPUs, RAM chips, entire motherboards, anything at all. You can rebuild it online while your transactions continue. Transactions can be run in duplicate across multiple hardware paths to ensure they are never lost and also verify output correctness.

If you set out to build a database server that handles 100 million transactions per hour and never ever goes down, you would end up with a mainframe.

I went through couple of mainframe z/OS basics certifications about 10y ago, never did anything commercial, just for educational purposes. All info comes from lectures and people who visited the cert-learning group with job offers.

A bit of history, mainframes are done by IBM which historically had some interesting things to do like count votes which led them into data processing market, mainframes were built for high data loads. You don't buy mainframe, you only rent it, physically. The level of duplication possible with these machines is incredible. You might receive a call, or maybe mail nowadays that something has broke in the mainframe you are using and you might be not aware it ever happened. I don't know if any "regular" vendor can tell you that e.g. half of 24 CPU board is broken down and they are going to replace it for you as this is their responsibility and would like to be sure someone can open the building with mainframe. Pro tip: you might be scared because you know you need 40 CPUs and that means you should have 2 such CPU boards and now you think you are missing 4 CPUs, but in reality you will learn that it's all ok and you will not face downtime because they can change it without switching it off and anyway you already had 3 boards just in case some failure happens and IBM does not want to send technicians back and forth multiple times a year for something as simple as this thing so they just have put more parts into your chassis and since telemetry is working all the time the know when they have to replace parts. On the software side you can run pretty much anything fancy there, the can emulate whatever you need if only enough clients have enough $$$ and this is how they can offer you CPUs with native java support, you don't run assembly there, you run JVM bytecode directly on CPU. And the more accurate software side, sometimes you have to deal with strange limitations, are they wrong? I don't know for sure, but I rather think not wrong. Mainframes can operate in backward compatible way and you are hostage to thinking of times when computers very in early evolving stage and world looked different. If you are writing web apps - which is pretty much kind of majority of work for devs in my experience - have you ever considered things like limits of the app you are writing? Can you estimate a number of users who can use app concurrently without measuring? Do you know upfront how much space for logs do you need? Maybe yes, but if you have to tell your operating system that you need space for 5 billions of log records and you have to provide record format with constant length strings and you have to do it upfront you might be surprised. You might be also surprised your operating system understands that your data is structured and has tools supporting you with processing such data. Log retention? This is operating system feature, you can specify that log is important for 3 such files and they should rotate, opearting system will notice when you cross boundary of 5 billion records and will create next dataset (not file, there are no files, different words for many of things). If datasets (000), (001) and (002) are full, then the oldest is removed and (004) starts its own life. Oh, did I mention you can specify these rotation only once when you create dataset :)? But only if you work in backward compatible mode which is compatible with tape drives.

There are lots of topics which I haven't covered and can relate looking at other comments, I'm not sure how much of the hardware things is really true because I couldn't verify it from software side, but on the other hand I have no reason to doubt the stories other than it being so uncommon in regular computing. I hope I did not make up things as I write old memories.

One thing which is not really mainframe related is the work culture around them. It is just different, to me it seems like it is build for STEM enthusiasts, people who prefer to plan then execute. From business side there is a need to do something and see money coming, this is where is key difference, I don't know if Agile would work in world of mainframes but I doubt. Of course there are deadlines too, but overall approach is different. And because a lot of things get planned or are considered before deploying the app, the apps come with books of procedures. If error QWE123 happens then please follow these 15 steps. This is where mainframe operators come (mentioned in other comments), I don't know why this work should be done by people, terminal which accesses mainframe can be programmed around and used just like rest API (or pretty close), but there must be something extra in having some analog processing unit in the loop. Playing with emulators is not enough, you will invent your own ways of doing some things which is undesired feature when you work with mainframes, they are supposed to be low maintenance, so there is sometimes probaly a little space in mature environments to come with own custom solutions. But on the other hand they are source of many already existing concepts, e.g. blue green deployments but with option to continue started operations with old versions. Completely invisible rollout of new app version.

Mainframes are fascinating for many reasons and while I know some of the features can be done in regular environments I have bad luck in choosing jobs. Companies hiring for mainframes usually offer all required trainings, what I don't understand is why they don't offer well above the market salary for work which is far more cumbersome than other things. I received offer to work in capital city of neighbouring country of similar economic situation and the offer while was about 30-40% than my actual first job did not please me at all, and I could do regular dev job in my own capital city for a little less than that if I wanted to. I worked for one proxy dev contracting job for company with thousands of people around the world and somehow my local managers took care about opportunity to work with mainframe so it never happens, somehow it was seen as bad opportunity, I guess it was problematic for local office to deal with probable security measurements.

While there is a lot to talk about there, I think all of those points are dwarfed by the main draw: legacy support. Companies running mainframes typically have decades worth of code that is running on the mainframes and the cost/risk of migrating is enormous for questionable gains.

I definitely agree accessibility is an issue. I am pretty young myself and found COBOL to be pretty easy to learn and start developing production applications with, in many ways easier than modern systems due to lower complexity for the dev. However, the systems side of things felt very alien to me and has been a challenge to learn. I don't know how one could learn it without training at a company that has a mainframe or by taking courses with IBM.