* 1 Evolution
* 1.1 Initial models * 1.2 Monolithic memory * 1.3 Virtual storage * 1.4 Subsequent enhancements
* 2 Expanding the address space
* 2.1 31 versus 32 bits
* 3 Series and models
* 3.1 Models sorted by date introduced (table)
* 3.2 Models grouped by Model number (detailed)
* 3.2.1 System/370 Model 115 * 3.2.2 System/370 Model 125 * 3.2.3 System/370 Model 135 * 3.2.4 System/370 Model 138 * 3.2.5 System/370 Model 145 * 3.2.6 System/370 Model 148 * 3.2.7 System/370 Model 155 * 3.2.8 System/370 Model 158 * 3.2.9 System/370 Model 165 * 3.2.10 System/370 Model 168 * 3.2.11 System/370 Model 195
* 3.2.12 System/370-compatible
* 3.3 Clones
* 4 Architecture details * 5 S/370 replacement * 6 GCC and Linux on the S/370 * 7 I/O evolutions * 8 See also * 9 Notes * 10 References * 11 External links
The original System/370 line was announced on June 30, 1970 with first customer shipment of the Models 155 and 165 planned for February 1971 and April 1971 respectively. System/370 underwent several architectural improvements during its roughly 20-year lifetime.
The first System/370 machines, the Model 155 and the Model 165 , incorporated only a small number of changes to the System/360 architecture. These changes included:
* 13 new instructions, among which were
* MOVE LONG (MVCL); :23-25 * COMPARE LOGICAL LONG (CLCL); :22-22
thereby permitting operations on up to 2^24-1 bytes (16 MB), vs. the 256-byte limits on the 360's MVC and CLC;
* SHIFT AND ROUND DECIMAL (SRP), which multiplied or divided a packed decimal value by a power of 10, rounding the result when dividing; :25-26
* optional 128-bit (hexadecimal ) floating point arithmetic, introduced in the System/360 Model 85 * a new higher-resolution time-of-day clock :6 * support for the block multiplexer channel :18 introduced in the System/360 Model 85.
These models had core memory and did not include support for virtual storage .
On September 23, 1970,
In 1972, a very significant change was made when support for virtual
storage was introduced with IBM's "System/370 Advanced Function"
* address relocation hardware on all S/370s except the original
models 155 and 165
* the new S/370 models 158 and 168, with address relocation hardware
* four new operating systems:
DOS/VS (DOS with virtual storage),
OS/VS1 (OS/360 MFT with virtual storage), OS/VS2 (OS/360 MVT with
virtual storage) Release 1, termed SVS (Single Virtual Storage), and
Release 2, termed
Virtual storage had in fact been delivered on S/370 hardware before this announcement:
* In June 1971, on the S/370-145 (one of which had to be "smuggled"
Cambridge Scientific Center to prevent anybody noticing the
arrival of an S/370 at that hotbed of virtual memory development –
since this would have signaled that the S/370 was about to receive
address relocation technology). (Varian 1997:p29 ) The S/370-145 had
an associative memory used by the microcode for the DOS
compatibility feature from its first shipments in June 1971; the same
hardware was used by the microcode for DAT. Although
Shortly after the August 2, 1972 announcement, DAT box (address
relocation hardware) upgrades for the S/370-155 and S/370-165 were
quietly announced, but were available only for purchase by customers
who already owned a Model 155 or 165. After installation, these models
were known as the S/370-155-II and S/370-165-II.
Later architectural changes primarily involved expansions in memory
(central storage) – both physical memory and virtual address space
– to enable larger workloads and meet client demands for more
storage. This was the inevitable trend as Moore\'s Law eroded the unit
cost of memory. As with all
* In October 1981, the 3033 and 3081 processors added "extended real addressing", which allowed 26-bit addressing for physical storage (but still imposed a 24-bit limit for any individual address space). This capability appeared later on other systems, such as the 4381 and 3090. * The S/370-XA architecture, first available in early 1983 on the 3081 and 3083 processors, provided a number of major enhancements, including: expansion of the address space from 24-bits to 31-bits ; facilitating movement of data between two address spaces; and a complete redesign of the I/O architecture. The cross-memory services capability which facilitated movement of data between address spaces was actually available just prior to S/370-XA architecture on the 3031, 3032 and 3033 processors. * The ESA/370 architecture (later named ESA/390 ) made further extensions, including the addition of sixteen 32-bit access registers , more addressing modes, and various facilities for working with multiple address spaces simultaneously.
EXPANDING THE ADDRESS SPACE
As described above, the S/370 product line underwent a major architectural change: expansion of its address space from 24 to 31 bits.
The evolution of S/370 addressing was always complicated by the basic S/360 instruction set design, and its large installed code base, which relied on a 24-bit logical address . (In particular, a heavily used machine instruction, "Load Address" (LA), explicitly cleared the top eight bits of the address being placed in a register. This created enormous migration problems for existing software.)
The strategy chosen was to implement expanded addressing in three stages:
* first at the physical level (to enable more memory hardware per system) * then at the operating system level (to let system software access multiple address spaces and utilize larger address spaces) * finally at the application level (to let new applications access larger address spaces)
Since the core S/360 instruction set remained geared to a 24-bit universe, this third step would require a real break from the status quo; existing assembly language applications would of course not benefit, and new compilers would be needed before non-assembler applications could be migrated. Most shops thus continued to run their 24-bit applications in a higher-performance 31-bit world.
This evolutionary implementation (repeated in z/Architecture ) had the characteristic of solving the most urgent problems first: relief for real memory addressing being needed sooner than virtual memory addressing.
31 VERSUS 32 BITS
IBM's choice of 31-bit (versus 32-bit) addressing for 370-XA involved various factors. The System/360 Model 67 had included a full 32-bit addressing mode, but this feature was not carried forward to the System/370 series, which began with only 24-bit addressing. When IBM later expanded the S/370 address space in S/370-XA, several reasons are cited for the choice of 31 bits:
* The desire to retain the high-order bit as a "control or escape bit." In particular, the standard subroutine calling convention marked the final parameter word by setting its high bit. * Interaction between 32-bit addresses and two instructions (BXH and BXLE) that treated their arguments as signed numbers (and which was said to be the reason TSS used 31-bit addressing on the Model 67). (Varian 1997:p26, note 85 ) * Input from key initial Model 67 sites, which had debated the alternatives during the initial system design period, and had recommended 31 bits (instead of the 32-bit design that was ultimately chosen at the time). (Varian 1997:pp8–9, note 21, includes other comments about the "Inner Six" Model 67 design disclosees)
SERIES AND MODELS
MODELS SORTED BY DATE INTRODUCED (TABLE)
The following table summarizes the major S/370 series and models. The second column lists the principal architecture associated with each series. Many models implemented more than one architecture; thus, 308x processors initially shipped as S/370 architecture, but later offered XA; and many processors, such as the 4381, had microcode that allowed customer selection between S/370 or XA (later, ESA) operation.
Note also the confusing term "System/370-compatible", which appeared
First year of series ARCHITECTURE Market level SERIES MODELS
1970 System/370 (no DAT) high-end System/370-xxx -155, -165, -195
1970 System/370 (DAT) mid-range -145 and -135
1972 System/370 high-end -158 and -168
entry -115 and -125
mid-range -138 and -148
1977 System/370-compatible high-end 303x 3031, 3032, 3033
1979 entry/mid 43xx 4331, 4341, 4361
1980 high-end 308x 3081, 3083, 3084
1983 mid-range 4381 4381
1986 high-end 3090 -120 to -600
1986 System/370-compatible entry 937x 9370, ...
1988 ESA/370 high-end ES/3090 ES/3090
1988 mid-range ES/4381 -90, -91, -92
MODELS GROUPED BY MODEL NUMBER (DETAILED)
System/370 Model 115
It was delivered with "a minimum of two (of IBM's newly announced)
The CPU could be configured with 65,536 (64K) or 98,304 (96K) bytes of main memory. An optional 360/20 emulator was available.
(The 115 was withdrawn Mar 9, 1981)
System/370 Model 125
Two, three or four directly attached
Main memory was either 98,304 (96K) or 131,072 (128K) bytes.
(The 125 was withdrawn Mar 9, 1981)
System/370 Model 135
A "reading device located in the Model 135 console" allowed updates and adding features to the Model 135's microcode.
(The 135 was withdrawn Oct 16, 1979)
System/370 Model 138
(The 138 was withdrawn Nov 1, 1983)
System/370 Model 145
Thr first System/370 to use monolithic main memory, the model 145 was
offered in six memory sizes. A portion of the main memory, the
"Reloadable Control Storage" (RCS) was loaded from a prewritten disk
cartridge containing all needed intructions as well as optional
instructions to enable the system to emulate earlier
The 145 was withdrawn Oct 16, 1979
System/370 Model 148
As with the option to field-upgrade a 135, a 370/145 could be field-upgraded "at customer locations" to 148-level performance. The upgraded 135 and 145 systems were "designated the Models 135-3 and 145-3."
System/370 Model 155
Both the 155 and the 165 were withdrawn Dec 23, 1977.
System/370 Model 158
It included Dynamic address translation (DAT) hardware, a pre-requisite for the new virtual memory operating systems (OS/VS1, OS/VS2).
A tightly coupled multiprocessor (MP) model was available, as was the ability to loosely couple this system to another 360 or 370 via an optional channel-to-channel adapter.
Emulation for 7070/7074, 1401/1440/1460, and 1410/7010 were included, and they could operate concurrently with standard System/370 workloads.
(The 158 and 168 were withdrawn Sep 15, 1980)
System/370 Model 165
Some have described the 360/85 's use of microcoded vs hardwired as a bridge to the 370/165
System/370 Model 168
Compatibility features included emulation for 7070/7074, 7080, and 709/7090/7094/7094 II .
Although the 168 served as IBM's "flagship" system, a 1975 newbrief
The 370/168 was not withdrawn until September, 1980.
System/370 Model 195
Its introduction came about 14 months after the announcement of the 360/195. Both 195 machines were withdrawn Feb. 9, 1977.
Beginning in 1977,
The first of the initial high end machines, IBM's 3033, was announced
March 25, 1977 and was delivered the following March, at which time a
multiprocessor version of the 3033 was announced.
These models introduced IBM's Extended Architecture 's 31-bit address capability and a new set of backward compatible "XA" software
All three systems were withdrawn Aug 4, 1987.
The next series of high-end machines, the
Other models were the 120, 120E, 150, 150E, 180, 300, 600, 600E, 600S. The 300 had 3 CPUs and the 600s had 6 CPUs. The others were uniprocessor systems.
IBM's offering of an optional vector facility (VF) extension for the
3090 came at a time when
The 200 and 400 were withdrawn May 5, 1989.
The first pair of
The 4331 was subsequently withdrawn November 18, 1981, and the 4341 February 11, 1986.
Other models were the 4321, 4361 and 4381.
The 4361 has "Programmable Power-Off -- enables the user to turn off the processor under program control"; "Unit power off" is (also) part of the 4381 feature list.
The 4381 Model Group 3 was dual-CPU.
This low-end system, announced October 7, 1986, was "designed to
satisfy the computing requirements of
Furthermore, it stated its awareness of the needs of small-to-medium
size businesses to be able to respond, as "computing requirements
grow," adding that "the
In the 360 era, a number of manufacturers had already standardized
upon the IBM/360 instruction set and, to a degree, 360 architecture.
Notable computer makers included
That changed in the 1970s with the introduction of the IBM/370 and
Gene Amdahl 's launch of his own company. About the same time,
Japanese giants began eyeing the lucrative mainframe market both at
home and abroad. One Japanese consortium focused upon
Some of the era's clones included:
63 . . . 47 . . . 31 . . . 15 . . . 00 (bit position)*
PROGRAM STATUS WORD / INSTRUCTION ADDRESS
PSW (40 bits) IA (24 bits) Program Status Word
* Note that
above, i.e., the most significant (leftmost) bit is designated as bit number 0.
S/370 also refers to a computer system architecture specification, and is a direct and mostly backward compatible evolution of the System/360 architecture :9 from which it retains most aspects. This specification does not make any assumptions on the implementation itself, but rather describes the interfaces and the expected behavior of an implementation. The architecture describes mandatory interfaces that must be available on all implementations and optional interfaces which may or may not be implemented.
Some of the aspects of this architecture are:
* Big endian byte ordering
* One or more processors with:
* A 64-bit Program status word (PSW) which describes (among other things)
* Timing facilities (Time of day clock, interval timer, CPU timer and clock comparator) * An interruption mechanism, maskable and unmaskable interruption classes and subclasses * An instruction set . Each instruction is wholly described and also defines the conditions under which an exception is recognized in the form of program interruption.
* A memory (called storage) subsystem with:
* 8 bits per byte * A special processor communication area starting at address 0 * Key controlled protection * 24-bit addressing
* Manual control operations that provide:
* A bootstrap process (a process called Initial Program Load or IPL) * Operator-initiated interrupts * Resetting the system * Basic debugging facilities * Manual display and modifications of the system's state (memory and processor)
* An Input/Output mechanism – which doesn't describe the devices themselves
Some of the optional features are:
* A Dynamic Address Translation mechanism that can be used to implement a virtual memory system * Floating point instructions
Because of the extensible nature of the interface specification, new interface could be devised without breaking the initial interface contract. Such examples are:
* ECPS:VM, a feature to assist the VM/370 operating system * ECPS:VSE, a feature to assist the DOS operating system
Great care was taken in order to ensure that further modifications to the architecture would remain compatible, at least as far as non-privileged programs were concerned. This philosophy predates the definition of the S/370 architecture and started with the S/360 architecture. If certain rules are adhered to, a program written for this architecture will run with the intended results on the successors of this architecture.
One of the key aspect that allows this compatibility is to define that unused fields are to be set to a predetermined value (usually 0) - and that using another value leads to an exception condition being recognized. :10 When the interface is modified, this unused field can then be used to alter the interface contract. A well formed program can then still produce the expected result even when executing on an implementation of the new interface.
Such an example is that the S/370 architecture specifies that the 64-bit PSW register bit number 32 has to be set to 0 and that doing otherwise leads to an exception. Subsequently, when the S/370-XA architecture was defined, it was stated that this bit would indicate whether the program was a program expecting a 24-bit address architecture or 31-bit address architecture. Thus, most programs that ran on the 24-bit architecture can still run on 31-bit systems; the 64-bit z/Architecture has an additional mode bit for 64-bit addresses, so that those programs, and programs that ran on the 31-bit architecture, can still run on 64-bit systems.
However, not all of the interfaces can remain compatible. Emphasis was put on having non control programs (called problem state programs) remain compatible. Thus, operating systems have to be ported to the new architecture because the control interfaces can (and were) redefined in an incompatible way. For example, the I/O interface was redesigned in S/370-XA making S/370 program issuing I/O operations unusable as-is.
The System/370 line was replaced by the
In 2000, the System/390 was replaced by the zSeries (now called IBM System z). The zSeries mainframes introduced the 64-bit z/Architecture , the most significant design improvement since the 31-bit transition. All have retained essential backward compatibility with the original S/360 architecture and instruction set.
GCC AND LINUX ON THE S/370
GNU Compiler Collection
As in System/360, peripherals attached to the system via channels, in this case, evolved as follows:
* The block multiplexer channel, previously available only on the 360/85 and 360/195, was a standard part of the architecture. For compatibility it could operate as a selector channel. * Also, as part of the DAT announcement, channels were upgraded to have Indirect Data Address Lists (a form of I/O MMU).
* ^ E.g., programs that depended on getting program interrupts for
alignment errors might fail.
* ^ "System/370 Announcement".