How Mainframe Architecture Makes All the Difference: Then and Now
Former IBM Systems magazine contributor Joseph Gulla returns as a TechChannel contributor to explain the nuances of mainframe architecture
Editor’s note: This is the first of two articles to be published this month exploring the nuances of mainframe architecture, part of a yearlong series titled “z/OS and Friends.” The article marks the return of contributor Joseph Gulla, who wrote for TechChannel’s predecessor, IBM Systems magazine, from 2011-2020.
The history of mainframe computing has been fascinating to experience and even more interesting to read about. I could never have imagined the engineering that went into mainframes without making a study of it. And today, what is happening is extraordinary in its depth and scope—and frankly, is not encumbered but rather fueled by the needs of the mainframe client base. This dance between the past and the future of the mainframe is my motivation in writing this article.
I started in IT as a COBOL programmer trainee in 1978. A company offered me a job programming but first I had to learn a language. I spent three months attending class and coding batch programs that we submitted to the system for Compile, Link and Go processing. They kept track of how many tries it took to get a clean compile and successful test results. They ranked us—twelve trainees in total. For our first program, they required us to punch the program using 80 column cards with (of course) a key punch.
During one of the classes, the instructor told us about our mainframe computer. It was big and had special needs so it was in its own room with other devices like disk drives and communication controllers. It was in a computer room.
My Introduction to Virtualization
With hardware out of the way, the instructor moved on to software. Our mainframe ran an operating system called MVS. When he explained the name, I immediately knew it was created by a bunch of engineers, not by marketing. Our operating system supported multiple jobs at a time (that was the M) and the jobs took advantage of virtual storage (that was the VS).
Virtual storage was a big deal, he explained, because whatever the imitations of real storage on the mainframe, each program didn’t have to worry about it because the operating system gave our programs a pretty big range of seemingly contiguous addresses that were ours to use.
The instructor said virtual storage came with some overhead but that all in all, it was worth it because it simplified programming and took advantage of dead time created by interrupts. He finished by saying that the architecture and features of the mainframe made it possible for MVS to assist programs to get their work done. That last point about interrupts and architecture didn’t make complete sense to me but later I figured some of it out on my own.
From COBOL Confidence to Practical Understanding
After I became a confident COBOL programmer, I circled back to the mainframe in the computer room. I understood the notion of architecture, but how did it apply to a computer? At the time, most IT departments had a library with the IBM books that were shipped with the products.
At lunch, I read through some books on current mainframe offerings from IBM, like S/370 Principles of Operation. I was fascinated reading about the CPU, registers, PSW, storage and what became my favorite feature, interrupts (of which there were six classes or types). Interrupts have a role in assisting multitasking. Here is a link to a more descriptive version of the S/370 book that I was reading decades ago. Review it for a compelling glimpse back in time.
I also stumbled upon the fetch/decode/execute cycle, which rang true to me because I had begun to study assembler language. I wondered—could this simple process, executed over and over again millions of times a second, really be the most important process in computer processing? Is this the beating heart? Yes it is, and page 5 of this chapter explains it in wonderfully clear terms.
My, How Things Have Changed
So that was 1979; what about now? Well, MVS is now z/OS and S/370 is now z/Architecture, and it supports z/OS, Linux and z/TPF. Today, on z/OS, multitasking is primarily achieved through a combination of the operating system’s ability to manage multiple processes concurrently.
This combination includes features such as virtual storage, interrupts and an amazingly refined scheduling algorithm. This algorithm uses the hardware capabilities of the IBM Z mainframe, particularly its support for simultaneous multithreading (SMT), which runs multiple threads on a single core. This allows for efficient multitasking across multiple applications and users. Here is a description of SMT when used with Java under CICS.
Multitasking Put Into Practice
Consider this for how multitasking works in practice. When a user submits a job to the system, z/OS creates a process for it and manages its execution within the virtual memory space. Let’s call this application execution.
Next, when a process needs to wait for an I/O operation, the operating system saves its execution state (its context) and switches to another ready process, efficiently utilizing the CPU. Let’s call this context switching.
Next, the operating system dynamically assigns threads to available processor cores based on workload demands, optimizing the utilization of the available processing power. Let’s call this SMT management. Want to read more? Try this.
That is activity from a z/OS point of view, what about the hardware?
How hardware makes virtual storage possible
Hardware enables virtual storage through dynamic address translation (DAT), the process of translating a virtual address during a storage reference into the corresponding real address. DAT is implemented by both hardware and software using page tables, segment tables, region tables and translation lookaside buffers.
How hardware makes interrupts possible
An interrupt is a hardware-enforced transfer of control within an I-stream engine (a type of processor that processes instructions in the order they appear in storage, one at a time). An interruption usually takes place after an instruction is completed and before interpretation of the next instruction is started. The logic built into z/Architecture support is enough to preserve the information necessary to return to the interrupted point of departure.
How does the scheduling algorithm and SMT work?
Simultaneous multithreading is the ability of a single physical processor to simultaneously dispatch instructions from more than one hardware thread context. Because there are two hardware threads per physical processor, additional instructions can run at the same time.
Simultaneous multithreading allows you to take advantage of the superscalar nature of the processor by scheduling two applications at the same time on the same processor. No single application can fully saturate the processor.
Today, the elegant dance between the mainframe infrastructure and the OS is even more nuanced and intimate than it has been in the past. Currently, we have mainframe infrastructure that is branded z16 which became available in 2022. It is the latest in a long line of mainframe architectures that have been developed over six decades, starting with System 360 announced in April 1964. I’ll have more on z16 in the next article.