A Guide to the IBM 3033 Processor Complex (1979) [pdf]

I don't think many VAX-11/780s were shipped with 64MB RAM, the ones I used had 2 or 4.

While I do find VMS much more understandable than MVS (it's a completely different branch of the Tree of Computing, as similar to modern PCs as the extremophiles that live next to volcanic chimneys in the bottom of the ocean are to us), I have to say the VAX competed with the much lower end machines in the 370 family. Also, you don't measure a mainframe's capacity in MIPS - The CPU is a small part of the of overall system and a lot of hardware goes to the multiple IO subsystems that offload the main CPUs so that they can keep running your applications while the rest of the system focus on pushing bits in and out of the system. It was considered a "minicomputer", in contrast to a proper computer such as the System/370.

The Cray designs and the IBM mainframes were built for different requirements. The Cray machines were designed for the highest possible processor speed while mainframes were much more geared towards business needs, where you do a lot of IO and just a little bit of processing on the data, before sending it back to tape.

I work in an IBM i shop and concur that it is a powerful and elegant machine. All the old hats who've worked on it for most of their life, at least in my experience, still refer to it as the AS/400, rather than referring to it as the IBM i (before it was called IBM i, it was called System i).

Despite this, I can confirm that many of our non-tech savvy users and managers think of the machine as old and antiquated simply because of the way most of our user-base interfaces with the machine (TN5250 connection - green screen). I kid you not, many of the managers think we'd be better off replacing our IBM i with a new out-of-the-box machine, despite the fact that we have decades of homegrown programs and processes that have been built and customized on the i.

Any idea how one would find hardware documentation? I have an old "small" mainframe and I'm curious about some of the hardware (backplanes, connector pin outs, etc) but after dozens of hours spent searching, I only found an SSA pinout by a curious hardware engineer.

For mine, I never had any and can't find any hardware documentation. One critical piece of my system, I was only able to find a single photograph on the internet, much less anything more informative.

At some point in the past twenty years IBM downsized its technical writing teams. When I started as an intern in 1990 there were ~250 people in the “Information Development” group in Poughkeepsie responsible for MVS, RACF, RMF and a variety of other mainframe products (plus hardware documentation). Today, there’s now maybe 20–25 people left in Poughkeepsie covering twice the workload as other products consolidated there (Endicott closed, Kingston closed, etc).

For many programming languages of the day, you didn’t need a stack when calling a subroutine.

Languages such as FORTRAN and COBOL didn’t allow recursive calls, and multi-processing wasn’t in the picture, so stack frames could just be given fixed addresses, for example just before the called function’s entry point.

Around 1960, Lisp and ALGOL changed that.

Some RISC architectures didn't have dedicated instructions/registers for the call stack either. That, in itself, isn't really an issue.

The real issue is that the original calling convention chosen by OS/360 / MVS / z/OS didn't feature a stack. It was based on the assumption that code would not be recursive/reentrant. Each routine would have a static memory block to save registers in. That was a software design issue (OS and compilers), not a CPU design issue. However, a lot of application code was written in COBOL and FORTRAN, which in their original versions didn't support recursion/reentrancy at all, and a top-down coding style discouraged recursion/reentrancy anyway, so this was less of an issue in practice than it might have been. And lots of other vendors in the 1960s (such as DEC and HP) made the same design decision.

Over time, the demand to support recursive/reentrant code became stronger. The first approach was to have each routine use GETMAIN (equivalent of malloc) to dynamically allocate a save area. This succeeded in providing recursion/reenterancy, but cost a lot in performance. Later they introduced the equivalent of a stack, called a "dynamic save area" (DSA) – rather than having each routine's prologue call GETMAIN to allocate a register save area, they'd just use a slice of that dynamic save area allocated once at the beginning of the program. Newer versions of z/OS introduce a new calling convention XPLINK, which is even closer to what other platforms do – it is more efficient, the stack grows in the normal way (top-down not bottom-up), and overflow is detected using a guard page instead of a manual check in every function prologue.

However, due to the demands of backward compatibility, z/OS has to support all three calling conventions – the original one without a stack, the legacy DSA calling convention, and the new XPLINK stack calling convention – complete with thunking macros to generate code so code using one can call code using the other. At least if you stick to C, the compiler handles all this for you, and you just have to declare which calling convention to use before you declare the function (via `#pragma linkage`). Rather similar to the situation with MS-DOS and 16-bit Windows, where each function had to declare which calling convention it wanted to use (cdecl, pascal, stdcall, fortran, etc)

One thing I found fun with MTS is that you can actually do a lot of stuff without being logged in.