Print Email

Three Tsunamis and a Boat

Be prepared for disruptions that will affect the mainframe

2/14/2018 1:45:20 PM | A tsunami “is a series of waves in a water body caused by the displacement of a large volume of water, generally in an ocean or a large lake. Earthquakes, volcanic eruptions and other underwater explosions (including detonations of underwater nuclear devices), landslides, glacier calvings, meteorite impacts and other disturbances above or below water all have the potential to generate a tsunami.”

As you may recall from the Christmas Eve Indian Ocean Tsunami in 2004, which was caused by a massive undersea earthquake, before the water rushed in—taking everyone and everything with it—it first retreated, exposing a great deal of shore that is normally deep underwater. The uninformed have been known to rush in from the beach and grab exposed treasures rather than running for higher ground when this happens. Then, the ocean invades, leaving a vast wake of destruction.

This is serious stuff: not only was the property damage unimaginably extensive and vastly expensive to recover from, but the loss of life was even greater, and there is no way to recover from that. You just move forward with who and what remain and start over.

But what if you had a boat? As long as you’re on top of the water, you should be able to ride out a storm, right? Maybe. If you don’t find yourself dragged inland and bashed into every fixed object from buildings to hills to power plants; or dragged far out to sea afterwards without the means to survive and find the shore.

So what does this all have to do with the mainframe, that big iron juggernaut that fearlessly powers the world economy?

It can be easy to think of the IBM Z platform as a geographic fixture as solid and immovable as a mountain. But the fact is, not only does it run the world economy, it also runs on that same economy, with all its ebbs and flows. While it’s like an aircraft carrier, compared to the speed boats of commodity consumer computing, it’s still subject to the forces that humanity faces.

And one of those forces is demographics. The Baby Boom happened a long time ago, ending in 1964, the same year the IBM System/360 mainframe was announced. Generations X, Y and Z have had many IT career options beyond the mainframe. So a tipping point—similar to the elasticity of the Earth’s crust as it draws back before leaping into the next earthquake—looms as the average age of mainframe technologists reaches a tipping point where there won’t be enough non-retired mentors to properly guide a new generation.

Tsunami 1: A Lack of Available Talent

Recent surveys show there are some new mainframers arriving on the platform. But they also indicate that nearly half could retire on a whim. See point five which points to page 11,  which indicates that 40 percent of mainframers have over 20 years of experience, 47 percent are 50 years old or older, and only 7 percent are under 30 years old. An example of this might be if a new manager is hired to take charge of the mainframe systems staff in an organization that doesn’t realize their critical value and then proceeds to treat them in a manner that triggers a mass retirement.

Many mainframe organizations are going to have sudden losses of critical staff and not have anyone available to take the reins. And training new people from scratch—with no mentors—when it takes five to 10 years to properly form a responsible mainframer, could jeopardize the platform that runs your business.

So, that’s the first tsunami, and it’s going to hit the world of mainframe hard, and very soon. You can start preparing for it, but if you haven’t already begun, it’s too late to be completely unaffected. Even if you have begun, unless you have some pretty attractive reasons for your best people to stay, you can anticipate them being lured away by desperate organizations that are willing to hire anyone who can spell SMP/E and pronounce DASD.

We’re going to survive it. Because the mainframe is that good, as are the people who will remain. But it might not be easy. And, it’s going to set us up for the next tsunami.

Tsunami 2: Mainframe Security

The second tsunami will be more than just a demographic aftershock. Because, while the first one will leave us understaffed and underexperienced, the second one will flood the locks.

Aside from the obvious pun about controlled waterways, what I mean by this is the security of the mainframe. Google mainframe security enthusiasts with names like “Soldier of Fortran” or “Big Endian Smalls” if you’d like to get nervous about how hackable the mainframe can be. (Read an IBM Systems Magazine interview with Soldier of Fortran Philip Young about mainframe security.)

I know, since 1973, IBM’s statement of integrity has been a solid guarantee that you can’t do anything to a mainframe that isn’t explicitly permitted by those who are in charge of the system. But that didn’t mean you could set and forget it. Which is exactly what, to varying degrees, some mainframe shops have done, because they might not have the spare staff time to look into every possible vulnerability and keep their systems properly patched, configured and secured.

Boom! Splash! Do you feel the boat rocking? Won’t you wish you’d done a bit more in 2018 to test the waters and get things more prepared? And so the mainframe is dragged upstream into vulnerable territory.

But we can’t hide, because our retirement funds, health insurance, bank accounts and taxes: all the systems of record that hold the records we rely on are mainframe systems. So the mainframe must go on.

Tsunami 3: Victims of Our Own Success

But we’re not out of the woods yet, because the biggest tsunami will be next to hit, and it’s the one that every mainframe professional hoped to avoid until they could retire: being a victim of success.

Yeah, sorry all you introverts who make the world go round and would rather keep the mainframe running as-is than market it as the platform for the next big idea, if that means you have to deal with all those idea people and their goals. They just discovered you.

Because here’s the biggest open secret in the IBM Z world: We don’t want more work! We’re happy with our comfortable little corner of the basement, invisibly keeping the world running and then going home to our families on those evenings and weekends that we’re not doing an upgrade. We like being Clark Kent, and we’re happy to let all the consumer electronics devices pretend to be the real thing.

Admit it: you’re in a meeting with other IT people and the CIO brings up a new project and wants to know who would like it on their platform. The Linux, UNIX and Windows people start scrapping for the opportunity, while the mainframers move their chairs a little bit farther from the table and hope everyone ignores them. Because if anyone—especially a fellow mainframer—dares pipe up and suggest putting the latest scheme on big iron, the first people to laugh at the idea will be the other mainframers in the room.

Too late. The first two tsunamis, and the fact that the mainframe survived and the world economy kept running, have woken visionaries up to the fact that there’s one platform that really, actually, genuinely works, and they’re all going to want a piece of it. And that piece will be the end of your peace.

Deal with it: It’s time we all grew up. The last tsunami will happen, and we are going to rock it.

Because, yes, the mainframe really is that good. And so are we mainframers.

The Future Is Now


Wake up: This has been a vision, not merely a dream. The tsunamis are coming, and the mainframe is your boat. Time to get ready for the future. Surf’s up!


Reg Harbeck has been working in IT and mainframes for more than 25 years, and is very involved in the mainframe culture and ecosystem, particularly with the SHARE Board and zNextGen and Security projects. He will be presenting on this topic at SHARE March 11 to 16 in Sacramento. If you’d like to join the conversation, Reg may be reached at Reg@Harbeck.ca.

Join Now!
Breaking Through CPU Roadblocks

Breaking Through CPU Roadblocks

The Warning Track implementation on the zEC12 and the Blocked Workload Support in z/OS provide mechanisms to clear lower-priority work out of the way without violating z/OS priority dispatching to any great extent.

Read more »

Genealogy of COBOL and HLASM

Genealogy of COBOL and HLASM

Tracing the roots of the 'Syntacticized Assembler' and other computer generations.

Read more »