In the mid-70s, my father worked in the American automotive industry in Michigan, and I visited him at work as a small boy.  He took me into the “computer room” (as they used to call datacenters) and sat me down at the terminal of the biggest, baddest system on the planet at the time: IBM System/370.  There were rows of blinking lights, switches, and indicators.  I was instructed to type something on the keyboard or flip a switch and the system’s blinking lights changed and then the real programmers got back to work.

The System/370 was the sequel over its predecessor, the System/360, which was one of the big turning points in computer history.  I’m not sure exactly what model my father’s employer had, but it was likely one of the 303x series.  In 1978, IBM announced that it was releasing a multi-processor version in the 303x line, which would give customers two cores, and I believe this was the first or one of the first multiprocessor system as we would think of them today.  This was 24-bit computing – 31-bit was still a few years ago.

To get one of these dual-core hot rods, on a 48-month purchase agreement, you’d be spending on the order of $154,130 per month for 8MB, or $182,130 for 16MB.  Or you could write a check for $7,160,000 or $8,050,000 and own it outright.  That got you CPU, RAM, two consoles, and power/cooling.  Disk, more terminals (there’s no “LAN network” in the modern sense here), card punch readers, floppy disks, etc. are all extra.

In 2022, most of us would chuckle over 16MB of RAM.  But I’ve spoken to old vets who say that with a single CPU and only 8MB of RAM, they were routinely supporting hundreds (hundreds!) of logged-on users doing active work, while also processing batch, talking to dozens of printers at the same time, and communicating with a galaxy of antique I/O equipment such as SNA terminals, communication multiplexers, etc.  These people were running applications, compiling, submitting jobs, etc. and doing the business of the enterprise.  This is before the “client/server” model.  Everyone logged into the same system.  It’s possible to do such with so little because the way the mainframe works is fundamentally different than Unix or Windows.

Keep in mind that the mainframe’s roots stretch back to a time before operating systems, and indeed you can watch blue-suited (well, in black and white) IBM nerds from the 1960s explain what a “monitor program” (OS) is because it was a new idea.  The mainframe spans from a purely mechanical time (pre-WWII) where computers were mainly sophisticated card sorters that you ran sets of paper through, into the virtual world where there is “always something running” (an OS, or a “monitor” in 60s parlance).  The 1940s and 1950s, computing was not far removed from “setting up electronic circuits” but as the 50s/60s progressed, the mainframe evolved modern computing.

To illustrate how different things have been in the past, originally IBM used non-volatile RAM: you could power off a system, move it, plug it back in, and it would be exactly back where you were.  No boot or anything, just exactly where it was the moment you powered it off (today, dynamic RAM is used).  Many hardware components have been broken out into sub-units.  For example, there are specialized components that let many mainframes speak to each other, or handle the communication complexities of hundreds of terminals, etc.

The mainframe is also very batch-oriented, where even interactive sessions feel like mini-batch sessions.  While there are many on-line applications, much of the work is “take this program and this dataset and run this job, putting the output over here” kind of work.  The entire environment supports this – there are sophisticated job-control subsystems and much of the OS is very record-/dataset-oriented rather than file-oriented.  There are of course some ideas that are common to all systems – for example, the idea of “booting a system” is called an “initial program load (IPL)” in the mainframe world, the concept of a “configuration area” (/etc on Unix, PARMLIB on the mainframe) is there, etc.  But fundamentally the environment is different.

Today, modern mainframes have gigabytes/terabytes of memory, use fast SSD/NVMe SAN storage, speak TCP/IP and host web sites, etc.  IBM has actually offered Linux on the mainframe since 2008.  Another mainframe innovation was virtualization and mainframes have been virtualizing operating systems since the 1970s.  Modern mainframes can run hundreds of Linux instances simultaneously, right alongside however many copies of z/OS (the current operating system) you wish.  Mainframes tend to still be physically big, but they’ve shrunk to refrigerator-sized and they’re not larger than some high-end Unix gear (Sun E15000, HP SuperDome, etc.) or racks of open systems.

BTW, the concept of sharing software also came from the mainframe community.

Mainframes are still expensive, but back in the 1970s, they  up the entire floor of a building with staggering electricity bills, mammoth cooling requirements, and a priesthood of acolytes to tend these mighty systems.

And you, dear LowEndBox reader, can have one of these $8 million piece of computing history for free.

Well, sort of.

OK, you can’t actually get a free IBM 3033 (and couldn’t afford to run it if you could!), but you can emulate them on modern hardware and run much faster than systems of that era.

IBM has placed its operating systems prior to the 31-bit era in the public domain…or rather, it was forced to after the US government noted that it had developed the software under contract for the government and by law, it’s public domain.  In general, though, IBM has been generally gracious about this computing history, continuing to offer manuals and downloads on its web site for systems it has not sold for decades.

The Hercules emulator allows you to run any mainframe operating system.  You can even run z/OS (the current mainframe OS) on it, though not legally.  The latest free (public domain) OS you can run is MVS 3.8j from 1981.

Personally, I tried to get into the mainframe years ago but found it too alien.  For one thing, you can’t login with ssh but rather need a TN3270 emulator.  They’re available for all platforms but it’s a sign that you’re heading into a foreign country.  When you do connect, it’s like using Unix for the first time: what do I type, what are the special keys, how do I “move around”, etc.  There’s no “prompt” in the same scrolling sense, for example, which immediately is a little disorienting.

However, in recent years there have sprung up various YouTube channels that can walk you through getting the mainframe up and running.  There has also been some software packaging which makes things much easier.  It’s very analogous to the work the BSD community did with NET/2, or what Linux distributions do with the kernel.  If you had to download, compile, and build Linux from scratch, not many could do it.  But installing a distro, where things are all setup for you, is pretty simple.  Same thing with modern packaging of MVS 3.8j, as expressed in the TK4- package.

To get the mainframe up and running on Hercules, I recommend following one of these two tutorials:

• Moshix’s YouTube tutorial for MVS 3.8 on Linux
• Moshix’s YouTube tutorial for MVS 3.8 on Windows

Moshix will walk you through it step by step and take you from “I’ve never logged into a mainframe in my life” to “I just submitted a COBOL program to calculate prime numbers viewed the batch job output” in an hour.  You’ll be installing Hercules, a TN3270 emulator, and the TK4- “turkey MVS” kit, which is the MVS 3.8j system setup and ready to go.  It’s sort of like if you hired a Linux sysadmin to install Linux, get it setup, take care of all the startup/shutdown permissions, configured users, etc. – that’s what TK4- is.  You can customize anything you want but it’s a solid, professionally setup system to start from.

It’s interesting to compare the “ecosystem” here to other operating systems:

• Programming: COBOL, assembler, high-level assembler, FORTRAN, PL/I, many others of the era
• Jobs/Scripting: JCL, REXX
• Editors: no vim or emacs, but the RFE and RPF environments have sophisticated editors in them

Needless to say, anything you have will run it just fine in terms of power.  Minimum specs are much higher for the emulator itself compared to what it’s emulating.  Hercules is most comfortable with 1GB of RAM, and will use as many or as few cores as you want to throw at it.  They recommend 1.5Ghz or faster processor.

I don’t think LowEndBox is going to see a lot of z/OS or even MVS 3.8j offers anytime soon, but it’s a fun and fascinating step back in time.  And since z/OS people are very short demand this day, if you like it, you can always step up to 2022 with IBM’s “z/OS Practitioner” certification.

• Author
• Recent Posts

raindog308

Dread Lord of LowEnd Content at LowEndBox

I'm raindog308, techno polymath and long-time LowEndTalk community Administrator. My technical interests include all things Unix, perl, python, golang, shell scripting, vintage operating systems such as MVS, and relational database systems such as Oracle, PostgreSQL, and MySQL.

I also enjoy using LEBs! I have an empire of little guys for VPNs, larger guys for apps, and big guys for databases and storage. When I'm not in front a screen I'm into German Shepherd dogs, quality knives, target shooting, theology, tabletop roleplaying games, and forest hiking.

I enjoy writing technical articles here on LowEndBox to help people get more out of their systems. You can find me on LowEndTalk @raindog308

Latest posts by raindog308 (see all)

• Crunchbits Discontinuing Popular Annual Plans – The Community Mourns! - November 20, 2024
• RackNerd’s Black Friday 2024: Bigger, Better, and Now in Dublin! - November 19, 2024
• It’s the Season of Giving and CharityHost Has Deals for You! - November 18, 2024