Way before working with Windows, I started off in IT as a database administrator and systems programmer, working on IBM (and later Amdahl) mainframe systems running the MVS operating system, CICS transaction processing system (basically, software that drives thousands of terminals at once), and Adabas database.  The first model I remember working with was an ES/9000, with (I believe) 512MB of memory and a roomful of 2.5GB 3380 disk drives (each the size of a filing cabinet).  Those were the days.

Of course now we have laptops with better specs than these mainframes.  And just like there are emulators that let you run old video games on your PC, you can actually get a mainframe emulator as well.  Called Hercules, it’s a fairly faithful emulation, and you can download a copy from http://www.hercules-390.org/.  OK, but then you need to actually have an OS to run on that emulator.  Since IBM still markets mainframes (e.g. z15) and the operating systems that run on them (z/OS), you would think there wouldn’t be any freely-available OSes (except maybe Linux/390, a weird idea that actually was somewhat popular).  But you’d be wrong – there are a number of them.  I think that’s a result of a technicality.  From the main archive at http://www.ibiblio.org/jmaynard/:

IBM, by corporate policy, does not assert copyright ownership of any software which it distributed without copyright notices.

Not surprisingly, IBM and every other software vendor now include copyright notices on their software (even though now it’s probably not required due to the copyright laws from 1978).  But hey, this is a “toy mainframe” project anyway, so I downloaded a copy of MVS 3.8 and installed it on a laptop.  That results in a structure like this:

To decode that, “DASD” is an abbreviation for “direct access storage device.”  We now call these “disk drives.”  In this case, they are virtual disk drives, kind of like VHDs.  But they contain the OS and all kinds of other stuff.  When you start up the virtual mainframe, it boots from those drives and starts a number of terminals, including a console session and a number of 3270 terminal sessions.

But the MVS OS still hasn’t been loaded.  And even though I was a systems programmer, that still wasn’t something that I typically did myself.  Back to the documentation, which includes the magic command:

That requires another definition.  “IPL” means “initial program load.”  You know, that process that PCs do automatically when they are powered on.  In this case, doing it manually provides more flexibility, as you can flip between locations/boot volumes to choose different OS versions or configurations.  It was fairly common to do this as part of a migration process – you can test out a new configuration and then go back to the previous version with a “quick” reboot.  So, ready for the magic command:

That then shifts the process to a separate 3270 console that asks for system parameters:

For that, another page provided some guidance:  Just press enter.  Then you can choose “GO” for a cold start of the OS.  Of course to do that, you need to specify “R 0,GO” which means “reply to message 0 with the answer GO.”  The next thing to start is JES2, the subsystem that processes batch jobs (basically, everything the system runs happens via a batch job).  Of course that failed:

But from the docs at http://www.bsp-gmbh.com/turnkey/cookbook/opmvs.html#MVSIPL, that’s normal so you can just restart JES2 using “S JES2” and then tell it to format with “r 1,format”.  A few confirmations later and the system is up and running, at which point you can sign in to a TSO session (“TSO” = time sharing option, basically one of the earliest shells):

The person who configured this setup had a sense of humor:

Because the “good” editor that is included with the non-free versions of MVS, ISPF, isn’t available without a license from IBM, a substitute called RPF (“Rob’s Programming Facility” – yes, really) has been provided.  That’s a confusing name to me, because we used a separate facility called ROSCOE (who remembers Computer Associates?) which had its own RPF, a scripting environment – kind of like VBScript and HTA rolled into one.  So in many ways, ROSCOE and its RPF feature taught me what I used later to create MDT – RPF was only slightly worse than VBScript and HTA.  In any case, this RPF lets you edit files and submit jobs.  Here’s a very simple example, which defines a job named HELLO with one step named STEP1 that runs a program called IEFBR14:

That job can then be submitted for processing just by typing “submit” at the top of the screen.  You can see it run on the console:

Success, the job started and completed.  So what is program IEFBR14 (which has its own Wiki page)?  It’s one built into MVS that is probably the simplest assembly language program ever written.  It was originally one statement:

BR R14

That says to branch to the address contained in register 14, which effectively means “return to caller.”  That was later changed to two instructions:

SR R15,R15
BR R14

The first instruction zeros out register 15, which is the return code (making sure the program returns 0, success) and then the second one exits.

Now, I also need to go on a tangent during my tangent.  It was fairly common with mainframe compiled code (much of it written in assembly) to have some extra “padding” at the end of the binary files.  That enabled tiny patches to be applied to the OS by finding the bad code, replacing a couple of bytes with a branch instruction to that “padding” and placing the new assembly instructions in the “padding.”  (If you were really brave, there were tools available to hot-patch the binaries in memory, while the process was running.)  High-level languages made that much more difficult, hence OSes like Windows typically replace entire files (although there are some back-end optimizations done with express updates to figure out a binary delta patch which can be used to get a similar benefit).  Eventually, you’ll run out of “padding” for patches, but by that point it might be worth releasing a new version.  Shades of Windows servicing, but with so many more binaries to worry about.

So what did you learn out of all of this?  Who cares, I was reminiscing.  After all, it is my blog 🙂  But I will summarize a couple of key points:

• Things have come a long way since the 90’s, so stop your whining about Windows, Linux, or any other OS (at least those with a shell).  It could be so much worse.
• Your skills always build on top of things you’ve done in the past, no matter how obscure.  Who would have ever guessed that working on mainframe RPFs would prepare you for working on Windows deployment tools or Windows servicing?

OK, back to work…