The Mainframe Vocabulary Problem, and Why It Matters | Hacker News Reader

The Mainframe Vocabulary Problem, and Why It Matters

mainframesociety.com

30 pointsrbanffy16 comments

This is, in some way, endemic to all branches of software. Every group of practitioners has a shared vocabulary - as the article says, it's exploiting an efficiency. If we all have a common language, we can speak more efficiently about what we're doing, and what needs to be done.

That said, how approachable that vocabulary is reflects how approachable the community around it is.

For instance, I've found the DevOps community to be very open and accessible to newcomers. There is shared language - orchestration, config management, even some acronyms like CI/CD - but they generally seem to use approachable language. I've also found the Python and Ruby communities to be very welcoming and willing to teach newcomers, and while I'm not involved in it, I've heard the Rust community really shines here.

On the other hand, one of the reasons I've stayed away from the security community is its propensity for acronyms. SIEMs, CSPMs, ASPMs, SASTs, DASTs, EDR tools, and maybe you've even got a CISSP cert.. It's not approachable, and I've found that many security practitioners wear knowledge of these acronyms as a badge of honor. I've found the networking community even more toxic: there are some pieces of software I've used for over 20 years, with forums I avoid like the plague, because many questions are answered with some variety of "Read the docs!" or "You don't KNOW?!?!"

If I were a benevolent-dictator-for-life and had to bootstrap a community, I'd be aiming to foster the former, not the latter.

Granted jargon can be jarring to outsiders. But the cultural problem is that smart, clever younger folks would rather talk in acronyms like AI, ML GPT, exits, cap table, vesting, etc.

Talk to anyone under 40 and they will tell you that mainframes are extinct, that Java is sooo old, COBOL: what's that? They could rewrite those dinosaur systems in a weekend's hackathon.

Mainframes are awesome, but they’ve achieved what the hyper scalers aspire to - complete market domination. They finished up in 1991 or so.

The problem is there’s no growth. There are no new customers, no new patterns or meaningful growth areas. It’s a career cul de sac, and when the bean counters at your big bank discover Oracle Cloud ROI is 6% more than you, you get nuked from orbit.

IBM Endicott is being demolished this month.[1] IBM hadn't been doing much there in the last 20 years, but now it's all being flattened.

[1] https://www.youtube.com/watch?v=VuPyfD5vdHo

This underestimates the switching costs from mainframes. As one CIO told me, it’s basically career suicide. You take a rock solid system that’s been working forever and embodies decades ago of knowledge and replace it with something that while modern and cheaper exposes you to massive risk.

CIOs have a bias to be wimps. It's easier to kick the can down the road.

I work with alot of orgs that have these things, both directly and from a association/conference perspective - it's starting to change because the new CIOs didn't grow up with mainframes, and are finding themselves with no alternatives other than expensive and increasingly ineffective contracts to operate these things. 1990 was 35 years ago, the old guys are dead - the can has been kicked off a cliff.

Surprise them telling that UNIX and C are double their age on average.

> There’s no need to discard the language of the mainframe—it’s part of the platform’s strength. But we do need to be deliberate about how we teach it. Too often, explanations stop at “what” something is, without digging into “why” it matters.

That's even assuming you got an explanation in the first place that wasn't an "ask your systems programmer" or some other high level administrative gatekeeping cabal of the greybeard operator that is too scared of a new kid on the block wanting to learn how to IPL metal from scratch. That's scared me mostly away from working with most of this. I don't want to learn the code per se -- I want to work with the metal.

A quick helper: https://www.ibm.com/docs/en/zos-basic-skills?topic=glossary-...

This is more a primer to IBM vocabulary, though. IBM midrange systems also "IPL," like the POWER6 in the next room which isn't a small system but definitely not a mainframe.

Yep, I learned the terms IPL and IML ("Initial Microprogram Load," more akin to a cold boot) when I worked on an IBM midrange system running DOS/VSE back in the 1980s.

> definitely not a mainframe.

Interestingly enough, as part of IBM's Eclipz Project - to share tech between their server lines - the POWER6 shared a lot of things with the z10 mainframe processor. To quote Wikipedia:

"The z10 processor was co-developed with and shares many design traits with the POWER6 processor, such as fabrication technology, logic design, execution unit, floating-point units, bus technology (GX bus) and pipeline design style, i.e., a high frequency, low latency, deep (14 stages in the z10), in-order pipeline. "

Before current AI you might’ve had to rely on brain damage inducing amounts of free association to connect the dots.. now it might actually be a hundred times easier to learn.

This is no different from any other computing domains, we are very good with three letter abreviations.

No mention of WENUS. Clearly this is just a brief summary.

The acronym density of mainframers communicating compares only to astronauts during EVAs, and is equally impenetrable to the non initiated.

Reply on news.ycombinator.com