Mainframes, Freight Trains and Education Pains
By David Robertson, guest blogger
When I was in college, I had an instructor that, for all intents and purposes, was viewed as a relic. He was a throwback from a time where there wasn’t a computer that wasn’t made by Honeywell, IBM, or Amdahl. He regularly spoke of a time when IBM was ITR (International Time Recording) and the first computers they made were time clocks, or when IBM, Harvard, and the Mother of Structured Programming, Grace Murray Hopper, were designing the ASCC (the MARK I) for World War II.
Routinely, he was referred to as the “booby prize” of teachers if you had Operating Systems with him. He spent a good two weeks on MVS (now known as z/OS) and OS400 on AS400 (IBM® i on Power Systems).
It evoked eye-rolls and headshakes from every 19-year-old. “Why are we doing this? Who cares?”
To be fair, I was in school in the early aughts, from 2001 to 2004; this type of talk was fully accepted. Anything that wasn’t a i586/AMD64 architecture was dead.
I took COBOL, Operating Systems, and anything else I could from this professor. He sold me with an analogy: “There are some workloads that are fine for a pickup truck. Taking a few things to the dump, moving someone with a small apartment. That’s a PC. There’s some stuff that requires something bigger. You’re supplying a supermarket with groceries, so you use a tractor-trailer. That’s a Mini (IBM i on Power). Sometimes you need something that hauls 50 tons of coal, 60 steel I-beams, or a thousand flats of 2 x 4s. You might be able to do that work with something smaller, but why would you take all those trips? You use a freight train. That’s a mainframe.”
Though I didn’t really get what the full impact was at the time, I’ve figured it out as I’ve worked in the IT industry, first as a programmer, then as a Systems Programmer and a DBA for z/OS. I’ve seen what those “why are we doing this” folks, who now are in middle and upper management, have done trying to make pickup trucks do what trains were made for.
You see, it’s quite passé these days not to slash a budget by dropping that big ole’, antiquated “mainframe” or “IBM i” item.
“It’s so expensive.”
“The development staff is secluded to just its languages. COBOL, PL/I, RPG, FORTRAN, who even needs that stuff anyway?”
“We’ve got an entire farm of PCs, and you’re telling me that we can’t run something, some huge set of distributed servers, to handle that work? Sure we can; sure we can.”
Sometimes it works the way they expect it. I suppose it must have a few times, because every college campus sounds about the same when it comes to “big iron” as it did when I went to school. Or worse, they’ve just completely forgotten about it.
And then enter the COBOL discussions of 2020. Suddenly every news organization on the planet is talking about it.
Boring you with statistics isn’t what I’m here for. I could tell you how many transactions there are in a day, or how many Fortune 50 companies run on the backs of mainframes. I feel like everyone’s very quickly coming to an understanding of how integral the large platform computers are. The numbers are certainly out there, and those of us who work in big financial and retail can tell you that they haven’t declined the way others had expected them to.
I’m not suggesting that every application is perfect for IBM Z and i platforms and their languages. However, it is certainly worth noting with z/VM and z/Linux that you can stand up hundreds of servers on a single mainframe LPAR and move that “antiquated” COBOL right on over to, well, still the mainframe.
What I am saying is that there are certain high availability, high importance, and high traffic applications that thrive on these platforms. Programmers should influence our educational institutions. We all need to ensure that future programmers and architects don’t begin thinking that “old” means “replaceable.”
That goes for IT executives as well—the folks that deans and presidents of your university and colleges pay attention to when they decide what our future will hold as far as support and development. It’s selfish to say that COBOL is on its way out if it’s only money that’s the concern. But, if you tell them how old it is, that it’s not Object Oriented or it doesn’t fit well with Agile, then…
You’re tapping into the vein of what those forward-thinking educators want. It’s a fun little bait-and-switch that’s been perpetrated on our young learners with bright futures. Now it suddenly has a nationwide stage.
We’ll all get through this. There are COBOL programmers out there. Everyone will get their checks eventually.
That said, it might be time to take my old professor out of retirement and let him again remind us of how important the trains are since all we seem to think about are the highways full of pickup trucks.
David Robertson graduated Cum Laude from Missouri State University’s CIS program and has spent almost 15 years working on the IBM z platform. He started his career at American National Insurance as a Programmer/Analyst in COBOL, writing and maintaining the online policy maintenance (CICS) and underwriting systems, along with batch renewal systems. He then moved to a systems area as a systems programmer with an emphasis on DB2 for zOS, where he supported around 20 subsystems on 5 LPARS doing installs, clones and upgrades, along with work on various other 3rd party products. He now works at Jack Henry as a Senior Systems programmer doing similar work on the z platform.