World Library  
Flag as Inappropriate
Email this Article


Article Id: WHEBN0007546002
Reproduction Date:

Title: System/370  
Author: World Heritage Encyclopedia
Language: English
Subject: MVS, IBM 801, XA, MUSIC/SP, VM (operating system), CP/CMS, ES EVM, IBM 4300, IBM 3179G, Delimiterless input
Publisher: World Heritage Encyclopedia


"IBM 370" redirects here. For the printer, see IBM 370 printer.
Designer IBM
Bits 32-bit
Introduced 1970
Design CISC
Type Register-Register
Encoding Variable (2, 4 or 6 bytes long)
Branching Condition code, indexing, counting
Endianness Big
General purpose 16
Floating point 4 64-bit
History of IBM mainframes 1952–present
Market name Architecture
700/7000 series varied
System/360 System/360
System/370 System/370
System/390 ESA/390
zSeries 900, 800, 990, and 890 z/Architecture
System z9
System z10
zEnterprise System (z196, zEC12)

The IBM System/370 (S/370) was a model range of IBM mainframes announced on June 30, 1970 as the successors to the System/360 family. The series maintained backward compatibility with the S/360, allowing an easy migration path for customers; this, plus improved performance, were the dominant themes of the product announcement. Improvements over the S/360 first released in the S/370 model range included:

  • standard dual-processor capability;
  • "monolithic main memory" based on integrated circuits instead of magnetic cores;[1]
  • full support for virtual memory through a new microcode floppy disk on the 370/145[2] and a hardware upgrade to include a DAT box on the 370/155 and 370/165; these were not announced until 1972;
  • 128-bit floating point arithmetic on all models.[NB 1]


The original System/370 line underwent several architectural improvements during its roughly 20-year lifetime. One very significant change was the introduction of virtual memory, which was first made generally available in 1972 via IBM's "System/370 Advanced Function" announcement. IBM had initially (and controversially) chosen to exclude virtual storage from the S/370 line.[3][4] The August 2nd, 1972 announcement included:

  • Address relocation hardware on all S/370s except the original models 155 and 165
  • The new S/370-158 and -168
  • 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 MVS (Multiple Virtual Storage) and planned to be available 20 months later (at the end of March 1974), and VM/370 – the re-implemented CP/CMS

Virtual memory 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' into 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[5]) The S/370-145 had relocation hardware (implemented in microcode) from its first shipments in June 1971. Although IBM famously chose to exclude virtual memory from the S/370 announcement, that decision was being reconsidered during the completion of the 145 engineering, due partly to virtual memory experience at CSC and elsewhere. The 145 microcode architecture simplified the addition of virtual memory, allowing this capability to be present in early 145s without the extensive hardware modifications needed in other models. However, IBM did not document the 145's virtual memory capability, nor annotate the relevant bits in the control registers and PSW that were displayed on the operator control panel when selected using the roller switches. Existing S/370-145 customers were happy to learn that they did not have to purchase a hardware upgrade in order to run DOS/VS or OS/VS1 (or OS/VS2 Release 1 – which was possible, but not common because of the limited amount of main storage available on the S/370-145).

Shortly after the August 2nd, 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. IBM wanted customers to upgrade their 155 and 165 systems to the widely-sold S/370-158 and -168.[6] These upgrades were surprisingly expensive ($200,000 and $400,000, respectively) and had long ship date lead times after being ordered by a customer; consequently, they were never popular with customers, the majority of whom leased their systems via a third-party leasing company. This led to the original S/370-155 and S/370-165 models being described as "boat anchors". The upgrade, required to run OS/VS1 or OS/VS2, was not cost effective for most customers by the time IBM could actually deliver and install it, so many customers were stuck with these machines running MVT until their lease ended. It was not unusual for this to be another four, five or even six years for the more unfortunate ones, and turned out to be a significant factor in the slow adoption of OS/VS2 MVS, not only by customers in general, but for many internal IBM sites as well.


Later architectural changes primarily involved expansions in memory (central storage) – both physical memory and virtual address space – to support 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 IBM mainframe development, preserving backward compatibility was paramount.

  • 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:

  1. First at the physical level (to enable more memory hardware per system)
  2. Then at the operating system level (to let system software access multiple address spaces and utilize larger address spaces)
  3. 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 that 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:

  1. The desire to retain the high-order bit as a "control or escape bit."[7] In particular, the standard subroutine calling convention marked the final parameter word by setting its high bit.
  2. 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[5])
  3. 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,[5] includes other comments about the "Inner Six" Model 67 design disclosees)

Series and models

The following table summarizes the major S/370 series and models. The second column lists the principal architecture associated with each series. Many models supported 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 in IBM source documents to describe certain products. Outside IBM, this term would more often describe systems from Amdahl Corporation, Hitachi Ltd., and others, that could run the same S/370 software. This choice of terminology by IBM may have been a deliberate attempt to ignore the existence of those plug compatible manufacturers (PCMs), because they competed aggressively against IBM hardware dominance.

First year
of series
Architecture Market
Series Models
1970 System/370 (no DAT) high-end System/370-xxx -155, -165, -195
1970 System/370 (DAT) mid-range -145[1] and -135
1972 System/370 high-end -158 and -168
entry -115 and -125
mid-range -138 and -148
1977 System/370-compatible[8] high-end 303x 3031, 3032, 3033
1979 entry/mid 43xx 4331, 4341, 4361
1980 high-end 308x 3081, 3083, 3084
1981 System/370-XA
1983 mid-range 4381 4381
1986 high-end 3090 -120 to -600
1986 System/370-compatible[9] entry 937x 9370, ...
1988 ESA/370 high-end ES/3090 ES/3090
1988 mid-range ES/4381 -90, -91, -92

Notable machines in the 370 range include the IBM 370/195, the IBM 370/168, the IBM 3033, the IBM 3090 mainframe/supercomputer with its optional vector facility (VF) extension, and the relatively inexpensive IBM 9370 tailored for small-to-medium size businesses.


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 Univac, RCA, English Electric, and the Soviet ES EVM. These computers weren't perfectly compatible, nor (except for the Russian efforts) were they intended to be.

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 eying the lucrative mainframe market both at home and abroad. One Japanese consortium focused upon IBM and two others IBM's competitors, which had become known as the BUNCH (Burroughs/Univac/NCR/Control Data/Honeywell). The latter efforts were abandoned and eventually all Japanese efforts focused on the IBM mainframe lines.

Some of the era's clones included:

S/370 replacement

The System/370 line was replaced by the IBM System/390 in the 1990s, and the architecture was similarly renamed from ESA/370 to ESA/390. This was essentially just a rename for marketing reasons, rather than major architectural change.

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

The GNU Compiler Collection (GCC) had a backend for S/370, but it became obsolete over time and was finally replaced by the S/390 backend. Although the S/370 and S/390 instruction sets are essentially the same (and have been consistent since the introduction of the S/360), GCC support for older systems has been abandoned.[10] Current support is available for machines supporting the full instruction set of System/390 Generation 5 (G5), the hardware platform for the initial release of Linux/390. However, a separately-maintained version of GCC 3.2.3 that supports the S/370 is available, known as GCCMVS.[11]

I/O evolutions

  • The block multiplexer channel, previously available only on the 360/85 and 360/195, was a standard part of the architecture[12]
  • Also, as part of the DAT announcement, channels were upgraded to support Indirect Data Address lists (allowing some form of I/O MMU)

Architecture details

IBM S/370 registers
31 . . . 23 . . . 15 . . . 07 . . . 00 (bit position)*
General-purpose registers
0 R0
1 R1
2 R2
3 R3
4 R4
5 R5
6 R6
7 R7
8 R8
9 R9
10 R10
11 R11
12 R12
13 R13
14 R14
15 R15
Floating-point registers
FP0 (bits 32–63) FP0
FP0 (bits 0–31)
FP2 (bits 32–63) FP2
FP2 (bits 0–31)
FP4 (bits 32–63) FP4
FP4 (bits 0–31)
FP6 (bits 32–63) FP6
FP6 (bits 0–31)
Control registers
Program status word
PSW (bits 0-31) Program Status Word (upper)
(bits 32-39) IA (bits 40-63)   Instruction address

* Note that IBM documentation numbers the bits in reverse order to that shown
  above, i.e., the most significant (leftmost) bit is designated as bit number 0.

S/370 also refers to a computer system architecture specification,[13] and is a direct and mostly backward compatible evolution of the System/360 architecture[14][15] 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
    • 16 32-bit General purpose registers
    • 16 32-bit Control registers
    • 4 64-bit Floating-point registers
    • 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:

Due to 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.[16] 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 running on the 24 bit architecture can still run on 31 bit systems and the new 64 bit system.

However, not all of the interfaces can remain compatible. Emphasis was put on having non control programs (called problem state programs) remain compatible.[17] 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.

See also



External links

This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.

Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.