announced the System/370 product family in September 1970.
Like the System/360
family which it replaced,
the System/370 computers were designed to
be general purpose systems which could be used in commercial and academic
Some of the products which were part of the initial announcement were:
- the Models 145, 155 and 165 systems (i.e. the actual mainframe
- the 200MB 3330-01 hard drive disk unit
- the 3830 magnetic tape control unit and associated 3420
magnetic tape drive
The Model 145 was IBM's first system to use bipolar Mp memory (i.e.
no core memory
The Model 155 was a faster system than the 145 with
8K of write-through cache
memory and instruction pre-fetch
The Model 165 was even faster yet with a 16K cache
, more instruction
pre-fetching than the 155 and operand pre-fetching.
The Models 155 and 165 used core memory.
Other milestones included:
- the Model 195 announced in 1971 was a faster version of the System/360 Model 95.
Like the Model 95, invalid stores to memory on a Model 195 could
result in an imprecise interrupt.
This meant that the operating system (and the programmer)
would not be able to determine exactly which store instruction had
Programmers didn't like this feature very much
as it made debugging programs more difficult.
- the Models 158 and 168 announced in August of 1972 were the first System/370 models to support dynamic address translation (i.e. virtual memory)
(the earlier System/360 Model 67 also supported dynamic address translation).
- the multiprocessor extension announced in 1973 which allowed two 158 or
168 processors to be coupled together into a multiprocessor system
(although I can't find a reference, I'm 99.9% certain that these were
symmetric multiprocessor systems).
- the Model 3033 announced in May of 1977 replaced the Model 168
(the 3033 was half the size, consumed half the power and cooling, and
was nearly twice as fast as the Model 168).
- systems with more than 16M of real memory were announced in about 1981.
- the Model 3084 announced in 1983 was IBM's first four-way SMP.
- the Model 3090 announced in 1985 provided 16,000 terabytes of user-addressible storage.
The announcement of the System/390 product family in 1990 marked the
end of the System/370 family from a marketing perspective much like
the System/370's announcement in 1970 had marked the end of the System/360 family
from a marketing perspective.
the virtual memory architecture was structured around 64K or 1M segments
containing 4K or 2K pages
EBCDIC character set support within certain instructions
Like the System/360, the System/370 I/O architecture consisted of:
- sixteen general purpose (i.e. integer) 32-bit registers
- four 64-bit floating point registers (also used for 32-bit operations and used in pairs for 128-bit operations)
- sixteen control registers (only visible in supervisor state)
- 24-bit address support (32-bit support was added later)
- integer, floating point and decimal arithmetic support
(floating point format was distinctly not compatible with IEEE 754)
- arithmetic and comparison instructions would set a two-bit condition
code which could be tested in conditional branch instructions
- system protection features including supervisor and user state
(i.e. kernel and user mode) and memory protection keys (isolates processes
without requiring virtual memory support and provides for read-only memory)
- one byte instruction opcode within
two, four and six byte long instructions broken down into the following
formats (the number in parentheses is the length of instructions of
the type being described):
- RR (2) - Register to Register operations
- RX (4) - Register to storage operations with an indeX register
- RS (4) - (mostly) Register to Storage operations
- SI (4) - Storage operations with an Immediate (i.e. constant) operand
- S (4) - a few Strange beasts
- SS (6) - Storage to Storage operations
each system performed extensive self-checks on a very wide variety of
operations which tended to ensure that failed hardware wouldn't result in
- I/O devices which provided storage and communication paths to the
I/O devices were attached to control units.
- Control units which were responsible for providing a logical view of the I/O devices to the operating system.
Control units were attached to channels.
- Channel which mediated the actual transfer of data between
the control unit and the system's memory.
Channels implemented an i/o programming language (called channel
programming) which was used by the operating system to perform
I/O operations on the I/O devices or control units.
The architecture was documented/described using hexadecimal
(as opposed to the modern trend to describe architectures using octal
Program interruption codes
0001 Operation exception
0002 Privileged exception
0003 Execute exception
0004 Protection exception
0005 Addressing exception
0006 Specification exception
0007 Data exception
0008 Fixed-point overflow exception
0009 Fixed-point divide exception
000A Decimal overflow exception
000B Decimal divide exception
000C Exponent overflow exception
000D Exponent underflow exception
000E Significance exception
000F Floating-point divide exception
Do these bring back any bad memories?
These were the user-visible exception types.
A few exception types which were only visible to the supervisor/kernel
(e.g. page translation exception) have been omitted.
Assuming no I/O conflict, IBM (apparently) guarantees that binaries
produced for 1965 machines will run unchanged on the current generation
of zSeries hardware.
Thoughts, reminiscences and random observations
- I've not been able to determine the memory sizes of the early System/370
I believe that the Model 145 first shipped with about 256K of memory but
I'm not sure.
- the System 360/67 was the first 360 or 370 with dynamic address translation which helped to make it the first computer architecture that I'm aware of
which was virtualizable.
This means that it was possible to implement an operating system
which could provide one or more multiple virtual machines (the first operating system to actually deliver virtualization would have been CP67/CMS).
I used the University of Alberta's 360/67 as a first year university student for about three months before it was replaced by one of the world's first Amdahl computers.
I can remember using the System/370 virtualization capability while developing
kernel-level software for the Michigan Terminal System's kernel
(called the University of Michigan MultiProgramming Supervisor or UMMPS for short).
- the System/370 product family was described by a formal computer architecture
description manual called the IBM System/370 Principles of Operation
(often abbreviated as "S/370 PofO" or just "PofO").
By taking the time and effort to define a formal architecture description,
IBM had laid a framework within which hardware and software designers
could develop successive generations of products.
Hardware developers used the PofO to know exactly how a new generation of hardware
should behave (i.e. appear to the programmer).
Software developers used the PofO to know how the machine behaved
in exquisite detail (i.e. it wasn't necessary to construct
experiments to figure out how the machine behaved).
My personal opinion is that the S/370 PofO
is one of the best written computer reference manuals of
It's actually possible to jump into the manual and get a
definitive answer to practically any System/370 related question one might
want to ask.
Compare that to the current style of so-called computer reference manuals
which seem to document by giving examples.
There are practically no examples in the S/370 PofO.
Instead, one gets clear, crisp and unambiguous descriptions of how a
System/370 system behaves.
What a novel concept!
- IBM's current zSeries product family is a rebranding of their
System/390 product family which is an evolutionary extension
to the System/370 product family which, in turn, was an evolutionary extension
to the earlier System/360 family (introduced on April 7, 1964).
That's 50 years and counting folks!
- (bragging time) I made the (quite minor) operating system changes
support what I believe to have been the first System/370 compatible
machine with 16M of real memory*.
This was an operating system used and developed by about a half dozen universities.
The machine was made by Amdahl Corporation (i.e. it wasn't an IBM mainframe).
* I have a bit of trouble believing that this claim is true. Specifically, I cannot imagine that IBM would not have had their operating systems able to run on their systems with 16M of memory before I made the minor changes to MTS required to make it run on systems with 16M of memory. On the other hand, I was told at the time by someone who should have known that the (minor) work I did was a worldwide first. I still remember the change that I made. It is possible that IBM did not need to make an equivalent change because their operating systems solved the problem differently than MTS did (the problem was figuring out, during the early IPL sequence, how much memory the machine had).
- "IBM Highlights, 1970-1984" PDF file located at
(last accessed 2002/10/04)
- "FAQ's for Products and Services" web page located at
(last accessed 2002/10/04)
- An online copy of "Computer Structures: Principles and Examples";
by Daniel P. Siewiorek, C. Gordon Bell and Allen Newell; Copyright ©
1982, 1971 McGraw-Hill, Inc.
(watch out for the mis-spelling of "structure" in the URL)
http://www.ulib.org/webRoot/Books/Saving_Bell_Books/SBN%20Computer%20Strucutres/(last accessed 2002/10/04)
- "System/370 Market Chronology of Productions & Services"
web page located at
(last accessed 2002/10/04)
- "IBM System/370 Principles of Operation" rev. GA22-7000-8; Copyright ©
1970, 1972, 1973, 1974, 1980, 1981 International Business Machines Corporation
- "IBM System/370 Reference Summary" fourth edition (November 1976) rev. GX20-1850-3;
Copyright © International Business Machines Corporation
- "When One Brain Just Is Not Enough! / The Scheduling of
Multiprocessor Systems"; by Joshua A. Toepfer; PDF file located at
(last accessed 2002/10/04)
- "The Evolution of the S/390" document available as a PDF at
(last accessed 2002/10/04)
- "Michigan Terminal System Archive" at http://archive.michigan-terminal-system.org/ (last accessed 2016/03/17)
I taught IBM AIX courses as an independent contractor for about a dozen years starting in 1994.
For what it's worth, the vast majority of opinions expressed above
haven't changed since the early 1980s. I have never been an IBM employee.