Hubbry Logo
IBM System/370IBM System/370Main
Open search
IBM System/370
Community hub
IBM System/370
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
IBM System/370
IBM System/370
IBM System/370
View on Wikipedia
from Wikipedia
System/370
DesignerIBM
Bits32-bit
Introduced1970
DesignCISC
TypeRegister–Register
Register–Memory
Memory–Memory
EncodingVariable (2, 4 or 6 bytes long)
BranchingCondition code, indexing, counting
EndiannessBig
PredecessorSystem/360
SuccessorS/370-XA, ESA/370, ESA/390, z/Architecture
Registers
General-purpose16× 32-bit
Floating-point4× 64-bit

The IBM System/370 (S/370) is a range of computers, from entry-level to mainframes, announced as the successors to the System/360 family on June 30, 1970. The series mostly[a] maintains 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. Like its predecessor, the System/370 became a dominant computing platform and was a major commercial success for IBM.[1]

Early 370 systems differed from the 360 largely in their internal circuitry, moving from the Solid Logic Technology hybrid integrated circuits containing separate transistors to more modern monolithic integrated circuits containing multiple transistors per integrated circuit, which IBM called Monolithic System Technology, or MST. The higher density packaging allowed several formerly optional features from the 360 line to be included as standard features of the machines, floating-point support for instance. The 370 also added a small number of new instructions.

At the time of its introduction, the development of virtual memory systems had become a major theme in the computer market, and the 370 was considered highly controversial as it lacked this feature. This was addressed in 1972 with the System/370 Advanced Function and its associated dynamic address translation (DAT) hardware. All future machines in the lineup received this option, along with several new operating systems that supported it. Smaller additions were made throughout the lifetime of the line, which led to a profusion of models that were generally referred to by the processor number. One of the last major additions to the line in 1988 were the ESA/370 extensions that allowed a machine to have multiple virtual address spaces and easily switch among them.

The 370 was IBM's primary large mainframe offering from the 1970s through the 1980s. Its level of success led to competition from plug-compatible manufacturers such as Amdahl Corporation, Hitachi, and others.[1] In September 1990, the System/370 line was replaced with the System/390. The 390, which was based on a new ESA/390 model, expanded the multiple memory concept to include full hardware virtualization[disputed (for: It was there earlier)  – discuss] that allowed it to run multiple operating systems at the same time.

Evolution

[edit]

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.[2] The 155 first shipped in January 1971.[3]: 643  System/370 underwent several architectural improvements during its roughly 20-year lifetime.[4][5][6][7][8][9][10]

The following features mentioned in the 11th edition of the System/370 Principles of Operation[4] are either optional on S/360 but standard on S/370, introduced with S/370 or added to S/370 after announcement.

  • Branch and Save
  • Channel Indirect Data Addressing
  • Channel-Set Switching
  • Clear I/O
  • Command Retry
  • Commercial Instruction Set[b]
  • Conditional Swapping
  • CPU Timer and Clock Comparator
  • Dual-Address Space (DAS)
  • Extended-Precision Floating Point[c]
  • Extended Real Addressing
  • External Signals
  • Fast Release
  • Floating Point[b]
  • Halt Device
  • I/O Extended Logout
  • Limited Channel Logout
  • Move Inverse[d]
  • Multiprocessing[e]
  • PSW-Key Handling
  • Recovery Extensions
  • Segment Protection
  • Service Signal
  • Start-I/O-Fast Queuing[11] (SIOF)
  • Storage-Key-Instruction Extensions
  • Storage-Key 4K-Byte Block
  • Suspend and Resume
  • Test Block
  • Translation[f]
  • Vector[g]
  • 31-Bit IDAWs

Initial models

[edit]

When the first System/370 machines, the Model 155 and the Model 165, were introduced, the System/370 architecture was described as an extension, but not a redesign, of IBM's System/360 architecture which was introduced in 1964.[12] The System/370 architecture incorporated only a small number of changes to the System/360 architecture. These changes included:[13]

  • 13 new instructions, among which were
  • MOVE LONG (MVCL);[14]
  • COMPARE LOGICAL LONG (CLCL);[15]
thereby permitting operations on up to 2^24-1 bytes (16 MB), vs. the 256-byte limits on the 360's MVC and CLC;[16][17]
  • SHIFT AND ROUND DECIMAL (SRP),[18] which multiplied or divided a packed decimal value by a power of 10, rounding the result when dividing;

These models had core memory and did not include support for virtual storage, as they lacked a DAT (Dynamic Address Translation) box

Logic technology

[edit]

All models of the System/370 used IBM's form of monolithic integrated circuits called MST (Monolithic System Technology) making them third generation computers. MST provided System/370 with four to eight times the circuit density and over ten times the reliability when compared to the previous second generation SLT technology of the System/360.[3]: 440 

Monolithic memory

[edit]

On September 23, 1970, IBM announced the Model 145, a third model of the System/370, which was the first model to feature semiconductor main memory made from monolithic integrated circuits and was scheduled for delivery in the late summer of 1971. All subsequent S/370 models used such memory.

Virtual storage

[edit]

In 1972, a very significant change was made when support for virtual storage was introduced with IBM's "System/370 Advanced Function" announcement. IBM had initially (and controversially) chosen to exclude virtual storage from the S/370 line.[3]: 479–484 [24] The August 2, 1972 announcement included:

  • 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 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
System/370-145 3D Rendering
3D Rendering of computer center with IBM System/370-145 and IBM 2401 tape drives
System/370-145 3D Rendering
System/370-145 system console.

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" 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).[25] The S/370-145 had an associative memory[26][27]: CPU 117-CPU 129  used by the microcode for the DOS compatibility feature from its first shipments in June 1971;[26] the same hardware was used by the microcode for DAT.[27]: CPU 139  Although IBM famously chose to exclude virtual storage from the S/370 announcement, that decision was being reconsidered during the completion of the 145 engineering, partly because of virtual memory experience at CSC and elsewhere. The 145 microcode architecture simplified the addition of virtual storage, 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 storage 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. The Reference and Change bits of the Storage-protection Keys, however, were labeled on the rollers, a dead giveaway to anyone who had worked with the earlier 360/67. 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 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.[28] 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.[29] 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.[28] 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[30] in the slow adoption of OS/VS2 MVS, not only by customers in general, but for many internal IBM sites as well.

Subsequent enhancements

[edit]

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 IBM mainframe development, preserving backward compatibility was paramount.[citation needed]

  • Operating system specific assist, Extended Control Program Support (ECPS). extended facility and extension features for OS/VS1, MVS[h] and VM.[i] Exploiting levels of these operating systems, e.g., MVS/System Extensions (MVS/SE), reduce path length for some frequent functions.
  • The Dual Address Space[31] (DAS) facility allows a privileged program to move data between two address spaces without the overhead of allocating a buffer in common storage, moving the data to the buffer, scheduling an SRB in the target address space, moving the data to their final destination and freeing the buffer. IBM introduced DAS in 1981 for the 3033, but later made it available for some 43xx,[32] 3031 and 3032 processors. MVS/System Product (MVS/SP) Version 1 exploited DAS if it was available.
  • 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.[33]
  • The System/370 Extended Architecture (S/370-XA), first available in early 1983 on the 3081 and 3083 processors, provided a number of major enhancements, including expansion of virtual address spaces from 24-bits to 31-bits, expansion of real addresses from 24 or 26 bits to 31 bits, and a complete redesign of the I/O architecture.
  • In February 1988, IBM announced the Enterprise Systems Architecture/370 (ESA/370) for enhanced (E) 3090 and 4381 models. It added sixteen 32-bit access registers, more addressing modes, and various facilities for working with multiple address spaces simultaneously.
  • On September 5, 1990, IBM announced the Enterprise Systems Architecture/390[34] (ESA/390), upward compatible with ESA/370.

Dual address space

[edit]

In 1981, IBM added the dual-address-space facility to System/370.[31] This allows a program to have two address spaces; Control Register 1 contains the segment table origin (STO) for the primary address space and CR7 contains the STO for the secondary address space. The processor can run in primary-space mode or secondary-space mode. When in primary-space mode, instructions and data are fetched from the primary address space. When in secondary-space mode, operands whose addresses defined to be logical are fetched from the secondary address space; it is unpredictable whether instructions will be fetched from the primary or secondary address space, so code must be mapped into both address spaces in the same address ranges in both address spaces. The program can switch between primary-space and secondary-space mode with the SET ADDRESS SPACE CONTROL instruction; there are also MOVE TO PRIMARY and MOVE TO SECONDARY instructions that copy a range of bytes from an address range in one address space to an address range in the other address space.[35]

Address spaces are identified by an address-space number (ASN). The ASN contains indices into a two-level table, structured similarly to a two-level page table, with entries containing a presence bit, various fields indicating permissions granted for access to the address space, the starting address and length of the segment table for the address space, and other information. The SET SECONDARY ASN instruction makes the address space identified by a given ASN value the current secondary address space.[35]

Extended real addressing

[edit]

The initial System/370 architecture has a 24-bit limit on physical addresses, limiting physical memory to 16 MB. Page table entries have 12 bits of page frame address with 4 KB pages and 13 bits of page frame address with 2 KB pages, so combining a 12-bit page frame address with a 12-bit offset within the page or a 13-bit page frame address with an 11-bit offset within the page produces a 24-bit physical address.[36]

The extended real addressing feature in System/370 raises this limit to 26 bits, increasing the physical memory limit to 64 MB. Two reserved bits in the page table entry for 4 KB pages were used to extend the page frame address. The extended real addressing is only available with address translation enabled and with 4 KB pages.[36]

Series and models

[edit]

Models sorted by date introduced (table)

[edit]

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 in IBM source documents to describe certain products. Outside IBM, this term would more often describe systems from Amdahl Corporation, Hitachi, 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
level		 Series Models
1970 System/370 (no DAT) high-end System/370-xxx -155, -165, -195
1970 System/370 (DAT) mid-range -145[37] and -135
1972 System/370 high-end -158 and -168
entry -115 and -125
mid-range -138 and -148
1977 System/370-compatible[38] 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[39] 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)

[edit]

IBM used the name System/370 to announce the following eleven (three-digit) offerings:

System/370 Model 115

[edit]

The IBM System/370 Model 115 was announced March 13, 1973[40] as "an ideal System/370 entry system for users of IBM's System/3, 1130 computing system and System/360 Models 20, 22 and 25."

It was delivered with "a minimum of two (of IBM's newly announced) directly attached IBM 3340 disk drives."[40] Up to four 3340s could be attached.

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 on March 9, 1981.

System/370 Model 125

[edit]

The IBM System/370 Model 125 was announced Oct 4, 1972.[41]

Two, three or four directly attached IBM 3333 disk storage units provided "up to 400 million bytes online."

Main memory was either 98,304 (96K) or 131,072 (128K) bytes.

The 125 was withdrawn on March 9, 1981.

System/370 Model 135

[edit]

The IBM System/370 Model 135 was announced Mar 8, 1971.[42] Options for the 370/135 included a choice of four main memory sizes; IBM 1400 series (1401, 1440 and 1460) emulation was also offered.

A "reading device located in the Model 135 console" allowed updates and adding features to the Model 135's microcode.

The 135 was withdrawn on October 16, 1979.

System/370 Model 138

[edit]

The IBM System/370 Model 138 which was announced Jun 30, 1976 was offered with either 524,288 (512K) or 1,048,576 (1 MB) of memory. The latter was "double the maximum capacity of the Model 135," which "can be upgraded to the new computer's internal performance levels at customer locations."[43]

The 138 was withdrawn on November 1, 1983.

System/370 Model 145

[edit]
Main article: IBM System/370 Model 145

The IBM System/370 Model 145 was announced Sep 23, 1970, three months after the 155 and 165 models.[37] It first shipped in June 1971.[3]: 643 

The 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 microcode to implement, for example, all needed instructions, I/O channels, and optional instructions to enable the system to emulate earlier IBM machines.[37]

The 145 was withdrawn on October 16, 1979.

System/370 Model 148

[edit]

The IBM System/370 Model 148 had the same announcement and withdrawal dates as the Model 138.[44]

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

[edit]
Main article: IBM System/370 Model 155

The IBM System/370 Model 155 and the Model 165 were announced Jun 30, 1970, the first of the 370s introduced.[45] Neither had a DAT box; they were limited to running the same non-virtual-memory operating systems available for the System/360. The 155 first shipped in January 1971.[3]: 643 

The OS/DOS[46] (DOS/360 programs under OS/360), 1401/1440/1460 and 1410/7010[47][48] and 7070/7074 [49] compatibility features were included, and the supporting integrated emulator programs could operate concurrently with standard System/370 workloads.

In August 1972 IBM announced, as a field upgrade only, the IBM System/370 Model 155 II, which added a DAT box.

Both the 155 and the 165 were withdrawn on December 23, 1977.

System/370 Model 158

[edit]

The IBM System/370 Model 158 and the 370/168 were announced Aug 2, 1972.[50]

It included dynamic address translation (DAT) hardware, a prerequisite for the new virtual memory operating systems (DOS/VS, 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.

The 158 and 168 were withdrawn on September 15, 1980.

System/370 Model 165

[edit]
Main article: IBM System/370 Model 165

The IBM System/370 Model 165 was described by IBM as "more powerful"[12] compared to the "medium-scale" 370/155. It first shipped in April 1971.[3]: 643 

Compatibility features included emulation for 7070/7074, 7080, and 709/7090/7094/7094 II.

Some have described the 360/85's use of microcoded vs hardwired as a bridge to the 370/165.[51]

In August 1972 IBM announced, as a field upgrade only, the IBM System/370 Model 165 II which added a DAT box.

The 165 was withdrawn on December 23, 1977.

System/370 Model 168

[edit]
Main article: IBM System/370 Model 168

The IBM System/370 Model 168 included "up to eight megabytes"[52] of main memory, double the maximum of 4 megabytes on the 370/158.[50]

It included dynamic address translation (DAT) hardware, a pre-requisite for the new virtual memory operating systems.

Although the 168 served as IBM's "flagship" system,[53] a 1975 newsbrief said that IBM boosted the power of the 370/168 again "in the wake of the Amdahl challenge... only 10 months after it introduced the improved 168-3 processor."[54]

The 370/168 was not withdrawn until September 1980.

System/370 Model 195

[edit]
Model 195 control panel

The IBM System/370 Model 195 was announced Jun 30, 1970 and, at that time, it was "IBM's most powerful computing system."[55]

Its introduction came about 14 months after the announcement of its direct predecessor, the 360/195. Both 195 machines were withdrawn Feb. 9, 1977.[56][55]

System/370-compatible

[edit]

Beginning in 1977, IBM began to introduce new systems, using the description "A compatible member of the System/370 family."[57][58]

IBM 303X
[edit]
Main article: IBM 303X

The first of the initial high end machines, IBM's 3033, was announced March 25, 1977[59] and was delivered the following March, at which time a multiprocessor version of the 3033 was announced.[60] IBM described it as "The Big One."[61]

IBM noted about the 3033, looking back, that "When it was rolled out on March 25, 1977, the 3033 eclipsed the internal operating speed of the company's previous flagship the System/370 Model 168-3 ..."[53]

The IBM 3031 and IBM 3032 were announced Oct. 7, 1977 and withdrawn Feb. 8, 1985.[57][62]

IBM 308X
[edit]
Main article: IBM 308X

Three systems comprised the next series of high end machines, IBM's 308X systems:

  • The 3081[63] (announced Nov 12, 1980) had 2 CPUs
  • The 3083[64] (announced Mar 31, 1982) had 1 CPU
  • The 3084[65] (announced Sep 3, 1982) had 4 CPUs

Despite the numbering, the least powerful was the 3083, which could be field-upgraded to a 3081;[64] the 3084 was the top of the line.[65]

These models introduced IBM's Extended Architecture's 31-bit address capability[66] and a set of backward compatible MVS/Extended Architecture (MVS/XA) software replacing previous products and part of OS/VS2 R3.8:

Number Name
565–279 Basic Telecommunications Access Method/System Product (BTAM/SP)
5668–978 Graphics Access Method/System Product (GAM/SP)
5740-XC6 MVS/System Product - JES2 Version 2
5685–291 MVS/System Product - JES3 Version 2
5665–293 TSO Extensions (TSO/E) for MVS/XA[67]
5665–284 MVS/Extended Architecture Data Facility Product (DFP) Version 1[68]

All three 308x systems were withdrawn on August 4, 1987.

IBM 3090
[edit]
Main article: IBM 3090

The next series of high-end machines, the IBM 3090, began with models[j] 200 and 400.[69] They were announced Feb. 12, 1985, and were configured with two or four CPUs respectively. IBM subsequently announced models 120, 150, 180, 300, 500 and 600 with lower, intermediate and higher capacities; the first digit of the model number gives the number of central processors.

Starting with the E[70] models, and continuing with the J and S models, IBM offered Enterprise Systems Architecture/370[71] (ESA/370), Processor Resource/System Manager (PR/SM) and a set of backward compatible MVS/Enterprise System Architecture (MVS/ESA) software replacing previous products:

Number Name
5685–279 BTAM/SP
5668–978 GAM/SP 2.0
5685–001 MVS/System Product-JES2 Version 3[72]
5685–002 MVS/System Product-JES3 Version 3[72]
5665–293 TSO Extensions (TSO/E) for MVS/XA
5685–285 TSO/E Version 1 Release 4
5685–025 TSO/E Version 2
5665–284 MVS/XA Data Facility Product (DFP) Version 1[68]
5665-XA2 MVS/XA Data Facility Product (DFP) Version 2.3
5665-XA3 MVS/DFP Version 3.1

IBM's offering of an optional vector facility (VF) extension for the 3090 came at a time when Vector processing/Array processing suggested names like Cray and Control Data Corporation (CDC).[73][74]

The 200 and 400 were withdrawn on May 5, 1989.

IBM 4300
[edit]
Main article: IBM 4300

The first pair of IBM 4300 processors were Mid/Low end systems announced Jan 30, 1979[75][76] as "compact (and).. compatible with System/370."

The 4331 was subsequently withdrawn on November 18, 1981, and the 4341 on February 11, 1986.

Other models were the 4321,[77] 4361[78] and 4381.[79]

The 4361 has "Programmable Power-Off -- enables the user to turn off the processor under program control";[78] "Unit power off" is (also) part of the 4381 feature list.[79]

IBM offered many Model Groups and models of the 4300 family,[k] ranging from the entry level 4331 to the 4381, described as "one of the most powerful and versatile intermediate system processors ever produced by IBM."[l]

The 4381 Model Group 3 was dual-CPU.

IBM 9370
[edit]
Main article: IBM 9370

This low-end system, announced October 7, 1986,[80] was "designed to satisfy the computing requirements of IBM customers who value System/370 affinity" and "small enough and quiet enough to operate in an office environment."

IBM also noted its sensitivity to "entry software prices, substantial reductions in support and training requirements, and modest power consumption and maintenance costs."

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 IBM 9370 system can be easily expanded by adding additional features and racks to accommodate..."

This came at a time when Digital Equipment Corporation (DEC) and its VAX systems were strong competitors in both hardware and software;[81] the media of the day carried IBM's alleged "VAX Killer" phrase, albeit often skeptically.[82]

Clones

[edit]

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 with the UNIVAC 9000 series, RCA with the RCA Spectra 70 series, English Electric with the English Electric System 4, and the Soviet ES EVM. These computers were not perfectly compatible, nor (except for the Russian efforts)[83][84] 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 eyeing the lucrative mainframe market both at home and abroad. One Japanese consortium focused upon IBM and two others from the BUNCH (Burroughs/Univac/NCR/Control Data/Honeywell) group of IBM's competitors.[85] The latter efforts were abandoned and eventually all Japanese efforts focused on the IBM mainframe lines.

Some of the era's clones included:

Architecture details

[edit]

IBM documentation numbers the bits from high order to low order; the most significant (leftmost) bit is designated as bit number 0.

IBM S/370 registers
General Registers 0–15

Two's complement value
0 31
Control Registers 0–15

See Principles of Operation[87]
0 31
Floating Point Registers 0–6

S Biased exponent Mantissa
0 1 7 8 31

Mantissa (continued)
32 63
S/370 Basic Control mode PSW[88]

Chan.
Mask 		I
O 		E
X 		Key 0 M W P Interruption Code
0 1 2 4 5 6 7 8 11 12 13 14 15 16 31

ILC CC Program
Mask 		Instruction Address
32 33 34 35 36 39 40 63
S/370 BC mode PSW abbreviations
Bits Field Meaning
0–5 Channel Masks for channels 0–5
6 IO I/O Mask for channels > 5
7 EX External Mask
8–11 Key PSW key
12 E=0 Basic Control mode
13 M Machine-check mask
14 W Wait state
15 P Problem state
16–31 IC Interruption Code[89]
32–33 ILC Instruction-Length Code[90]
34–35 CC Condition Code
36–39 PM
Program Mask
Bit Meaning
36 Fixed-point overflow
37 Decimal overflow
38 Exponent underflow
39 Significance
40–63 IA Instruction Address
S/370 Extended Control mode PSW[91]

0 R 0 0 0 T I
O 		E
X 		Key 1 M W P S 0 CC Program
Mask 		0 0 0 0 0 0 0 0
0 1 2 4 5 6 7 8 11 12 13 14 15 16 17 18 19 20 23 24 31

0 0 0 0 0 0 0 0 Instruction Address
32 63
S/370 EC mode PSW abbreviations
Bits Field Meaning
1 R PER Mask
5 T DAT mode
6 IO I/O Mask; subject to channel mask in CR2
7 EX External Mask; subject to external subclass mask in CR0
8–11 Key PSW key
12 E=1 Extended Control mode
13 M Machine-check mask
14 W Wait state
15 P Problem state
16 S Address-Space Control
0=primary-space mode
1=Secondary-space mode
18–19 CC Condition Code
20–23 PM
Program Mask
Bit Meaning
20 Fixed-point overflow
21 Decimal overflow
22 Exponent underflow
23 Significance
40–63 IA Instruction Address

S/370 also refers to a computer system architecture specification,[92] and is a direct and mostly backward compatible evolution of the System/360 architecture[93] 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 does not describe the devices themselves

Some of the optional features are:

IBM took great care to ensure that changes to the architecture would remain compatible for unprivileged (problem state) programs; some new interfaces did not break the initial interface contract for privileged (supervisor mode) programs. Some examples are

ECPS:MVS[94]
A feature to enhance performance for the MVS/370 operating systems
ECPS:VM[95]
A feature to enhance performance for the VM operating systems

Other changes were compatible only for unprivileged programs, although the changes for privileged programs were of limited scope and well defined. Some examples are:

ECPS:VSE[96]
A feature to enhance performance for the DOS/VSE operating system.
S/370-XA[66]
A feature to provide a new I/O interface and to support 31-bit virtual and physical addressing

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.

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.[97] 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.

S/370 replacement

[edit]

IBM replaced the System/370 line with the System/390 in the 1990s, and similarly extended the architecture from ESA/370 to ESA/390. This was a minor architectural change, and was upwards compatible.

In 2000, the System/390 was replaced with the zSeries (now called IBM Z). The zSeries mainframes introduced the 64-bit z/Architecture, the most significant design improvement since the 31-bit transition.[citation needed] All have retained essential backward compatibility with the original S/360 architecture and instruction set.

GCC and Linux on the S/370

[edit]

The GNU Compiler Collection (GCC) had a back end for S/370, but it became obsolete over time and was finally replaced with 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 operability on older systems has been abandoned.[98] GCC currently works on machines that have 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 works for the S/370 is available, known as GCCMVS.[99]

I/O evolutions

[edit]

I/O evolution from original S/360 to S/370

[edit]
Main article: IBM System/360 § Channels

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.[100] Block multiplexer channels were available in single byte (1.5 MB/s) and double byte (3.0 MB/s) versions.

I/O evolution since original S/370

[edit]

As part of the DAT announcement, IBM upgraded channels to have Indirect Data Address Lists (IDALs). a form of I/O MMU.

Data streaming channels had a speed of 3.0 MB/s over a single byte interface, later upgraded to 4.5 MB/s.

Channel set switching allowed one processor in a multiprocessor configuration to take over the I/O workload from the other processor if it failed or was taken offline for maintenance.

System/370-XA introduced a channel subsystem that performed I/O queuing previously done by the operating system.

The System/390 introduced the ESCON channel, an optical fiber, half-duplex, serial channel with a maximum distance of 43 kilometers. Originally operating at 10 Mbyte/s, it was subsequently increased to 17 Mbyte/s.

Subsequently, FICON became the standard IBM mainframe channel; FIbre CONnection (FICON) is the IBM proprietary name for the ANSI FC-SB-3 Single-Byte Command Code Sets-3 Mapping Protocol for Fibre Channel (FC) protocol used to map both IBM's antecedent (either ESCON or parallel Bus and Tag) channel-to-control-unit cabling infrastructure and protocol onto standard FC services and infrastructure at data rates up to 16 Gigabits/sec at distances up to 100 km. Fibre Channel Protocol (FCP) allows attaching SCSI devices using the same infrastructure as FICON.

See also

[edit]

Notes

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

IBM System/370

View on Grokipedia
from Grokipedia
The IBM System/370 is a family of mainframe computer systems introduced by IBM in 1970, designed to meet the growing data processing demands of the era, including support for large databases, multiprocessing, and virtual memory capabilities while maintaining full backward compatibility with the System/360 architecture. It featured models ranging from entry-level to high-performance configurations, such as the Models 115, 125, 135, 145, 155, 158, 165, 168, and 195, with real storage capacities from 64K to 8M bytes and virtual storage up to 16M bytes across the lineup. Building on the System/360's instruction set and binary compatibility, the System/370 introduced key innovations like dynamic address translation (DAT) for efficient virtual storage management, storage protection keys (0-15), and high-speed silicon chip memory, replacing older ferrite core technology to achieve performance gains of up to five times faster than comparable System/360 models. These advancements enabled robust support for operating systems including OS/VS1, OS/VS2, DOS/VS, and VM/370, facilitating diverse applications in batch processing, time-sharing, teleprocessing, and industry-specific tasks like banking and scientific computing. The architecture also incorporated enhanced input/output channels (byte multiplexer, selector, and block multiplexer) and features for reliability, availability, and serviceability (RAS), such as error correction, instruction retry, and recovery management, which improved system uptime and data integrity. The System/370's impact was profound, dominating the mainframe market through the 1970s and 1980s by enabling scalable multiprocessing configurations and supporting the Virtual Storage Access Method (VSAM) for advanced data handling with key-sequenced and entry-sequenced datasets. It paved the way for subsequent developments, including the System/370 Extended Architecture (370-XA) in the 1980s and the eventual transition to the System/390 in 1990, while its emphasis on compatibility and virtual machine support influenced modern computing paradigms for virtualization and resource sharing.

Overview

Historical Context and Announcement

The IBM System/370 emerged as the direct successor to the IBM System/360, a groundbreaking family of compatible mainframe computers announced in 1964 that revolutionized data processing by standardizing IBM's disparate product lines into a single architecture. While the System/360 offered significant scalability and performance gains—up to five times faster than prior models for certain tasks—it was constrained by its reliance on fixed real memory addressing, which struggled to accommodate the escalating memory requirements of emerging applications like large-scale databases and multiprogramming environments in the late 1960s. To overcome these shortcomings without disrupting the vast installed base of System/360 software and peripherals, IBM engineered the System/370 with a focus on binary compatibility and enhanced architectural features, including the eventual integration of virtual storage to enable more efficient memory management for growing computational workloads. This approach preserved customer investments while extending the platform's viability into the 1970s, addressing the need for systems that could handle remote computing and complex transaction processing. On June 30, 1970, IBM formally announced the System/370 family during a major product unveiling, introducing initial models such as the 155 and 165 as upgrades optimized for the decade's demands. Marketed as a mid-to-high-end mainframe lineup, it targeted enterprise users requiring robust, scalable computing; for instance, the Model 155 with 768,000 bytes of main memory carried a purchase price of $2,248,550 and a monthly rental of $47,985. The first customer orders, including four units placed by State Street Bank and Trust Company on announcement day, underscored immediate market interest, with initial shipments commencing in early 1971. Virtual storage, a key innovation to further mitigate memory limitations inherited from the System/360, was introduced as an advanced function on August 2, 1972, alongside compatible models like the 158 and 168, allowing programs to operate in a larger virtual address space than physical memory permitted.

Core Design Objectives

The IBM System/370 was engineered with backward compatibility to the System/360 instruction set as a paramount objective, ensuring that the vast installed base of System/360 software and peripherals could transition seamlessly without requiring reprogramming or hardware redesign. This design choice protected IBM's customer investments and minimized disruption in enterprise environments, allowing most existing programs to execute unchanged on System/370 models. As articulated in early planning, System/370 was required to be fully upward compatible with System/360 to avoid forcing customers to "start over from scratch." A core innovation in System/370's architecture was the introduction of virtual storage, aimed at expanding addressable memory beyond physical limitations to support more complex applications without necessitating proportional increases in hardware costs or real memory capacity. This feature enabled programs to operate in address spaces up to 16 million bytes using dynamic address translation hardware, facilitating demand paging from auxiliary storage and reducing the need for manual overlays in programming. By implementing segmentation and paging mechanisms, virtual storage addressed key limitations of prior systems, allowing efficient resource allocation and independence from main storage size constraints. System/370 placed a strong emphasis on reliability, availability, and serviceability (RAS) as foundational design goals, incorporating hardware features to detect, correct, and recover from errors while simplifying maintenance in mission-critical operations. Central to this was the integration of error-correcting code (ECC) memory, which automatically corrected single-bit errors in processor storage and detected multi-bit failures, thereby enhancing data integrity without halting system functions. Additional RAS elements included automatic CPU retry mechanisms (up to seven attempts for transient faults), expanded machine-check interrupts for error classification, and online test and diagnostic programs (OLTEP and OLTs) that enabled non-disruptive fault isolation and repair. These provisions extended the architecture's focus on error handling and monitoring to support continuous availability in high-stakes environments. Scalability was another key objective, with System/370 designed to accommodate a wide spectrum of workloads including scientific computations, commercial data processing, and multiprogramming environments through modular expansions and performance optimizations. The architecture supported growth from smaller System/360 configurations to large-scale operations, handling simultaneous execution of multiple programs via enhanced channel capacities (up to 12 channels with over 9 MB/s aggregate throughput) and high-speed I/O devices like the 3330 disk system. This versatility enabled efficient resource sharing and dynamic partitioning, making it suitable for emerging demands such as large databases and teleprocessing in the 1970s.

Evolution and Technological Advancements

Initial Implementation and Models

The initial implementation of the IBM System/370 focused on extending the System/360 architecture with virtual memory support while maintaining full compatibility, beginning with mid-range models in 1970 and expanding to entry-level systems by 1973. The first models introduced byte-addressable main memory using semiconductor technology, integrated I/O channels compatible with System/360 peripherals, and microprogrammed control for efficient instruction execution. These foundational designs emphasized reliability through features like error correction in memory and instruction retry mechanisms, enabling a smooth transition for existing System/360 users to enhanced performance levels. Entry-level models provided cost-effective entry points into the System/370 family, targeting users upgrading from smaller systems like the System/360 Model 20 or System/3. The Model 115, announced on March 13, 1973, operated primarily in a 16-bit emulation mode compatible with the System/360 Model 20, supporting basic commercial applications with integrated attachments for printers, card readers, and direct disk access. It featured byte-addressable monolithic main storage of 64 KB or 96 KB, a 480 ns cycle time, and low-end performance suitable for basic commercial applications, equivalent to System/360 Model 20/25, using a decentralized architecture with multiple processors for machine instructions, service functions, and I/O handling. One byte multiplexer channel was standard, with up to three additional channels optional, all compatible with System/360 byte-multiplexer and selector types for attaching legacy peripherals like the 1403 printer and 3330 disk drives. The Model 125, announced on October 4, 1972, built on the 115 by introducing full System/370 native mode operation, allowing direct execution of virtual storage instructions without emulation overhead. It supported main memory configurations of 98 KB or 128 KB, also with a 480 ns cycle time, and included enhanced I/O capabilities such as string switching for up to four disk units and an integrated communications adapter equivalent to a byte multiplexer channel with 12 subchannels. Performance was approximately 2/3 that of the Model 135, suitable for teleprocessing and scientific workloads, while retaining System/360 channel compatibility for seamless peripheral integration. The physical configuration emphasized modularity, with the 3125 processing unit housing CPU, I/O processors, and optional expansions in a compact cabinet. Mid-range models offered higher performance for growing data processing needs, utilizing advanced logic technologies for denser circuitry. The Model 145, announced on September 23, 1970, was the first System/370 to employ semiconductor main memory fabricated on single silicon chips, replacing magnetic core storage and enabling up to 2 MB of byte-addressable memory with cycle times of 540 ns read and 607.5 ns write. It delivered performance up to four times that of the System/360 Model 40, supported by hybrid thick-film and integrated circuit (IC) logic in its Monolithic System Technology (MST), and included standard byte multiplexer and selector channels for up to five total I/O paths, fully compatible with System/360 devices. Features like high-speed buffer storage and error correction enhanced reliability for commercial and scientific applications. The Model 135, announced on March 8, 1971, complemented the 145 with similar hybrid thick-film and IC logic but targeted intermediate users upgrading from System/360 Models 25 or 30. It provided main memory from 98 KB to 1 MB, with cycle times of 770 ns read and 935 ns write per 2 bytes, and performance about 1.5 times that of the System/360 Model 40. Standard configuration included one byte multiplexer channel expandable to four, plus selector channel support, ensuring compatibility with System/360 I/O subsystems like the 3330 disk and 2400 tape series. The 3135 processing unit incorporated instruction retry and integrated file adapters for efficient direct access storage, making it a versatile mid-range option.

Logic and Memory Innovations

The IBM System/370 represented a pivotal shift in logic circuitry design by adopting Monolithic System Technology (MST), which employed fully integrated monolithic circuits on silicon chips rather than the hybrid modules of the prior System/360 series. This transition, evident across all System/370 models but particularly advanced in the 158 and 168 introduced in 1972, allowed for four to eight times greater circuit density, enhanced reliability through batch fabrication, and reduced physical footprint compared to the Solid Logic Technology (SLT) hybrids that combined discrete components on ceramic substrates. MST modules, typically measuring half an inch square, integrated multiple logic gates per chip using bipolar transistor technology, enabling clock speeds up to 25 MHz in high-end configurations and supporting microprogrammed control via dense read-only storage (ROS) and writable control storage (WCS). A major memory innovation in the System/370 was the widespread adoption of monolithic semiconductor memory, supplanting magnetic core storage and yielding dramatic reductions in size, cost, and power usage while improving access speeds. The Model 145, announced in 1970, pioneered this with all main memory elements on silicon chips, but the 1972 Models 158 and 168 further refined it using low-cost metal oxide semiconductor (MOS) chips that supported up to 8 MB of volatile storage with non-destructive readout and 4-way doubleword interleaving to minimize contention between CPU and channel requests. These advancements made memory expansion more economical—up to 8 times denser than core—and facilitated virtual storage implementations, with high-speed buffer storage scaling from 16 KB to 32 KB in later variants. To maintain data integrity in these denser semiconductor environments, the System/370 integrated error detection and correction hardware, including Error Correction Code (ECC) for main memory that automatically corrected single-bit errors and detected double-bit errors across doublewords, a standard feature in models from the 145 onward. Channel interfaces relied on parity bits for error detection during data transfers, ensuring reliable I/O operations without correction overhead. These mechanisms significantly reduced downtime from soft errors, which were more prevalent in early MOS technology. Power and cooling innovations addressed the thermal challenges of high-performance MST logic and large MOS arrays, particularly in upper-end models. The System/370 Model 195, a high-speed variant compatible with System/370 architecture, employed a water-based coolant distribution unit to circulate liquid through processor modules, dissipating up to 79 kW of heat from densely packed circuitry operating at elevated frequencies. This hybrid air-liquid system, requiring three power units and precise facility water flow (35–100 GPM), enabled sustained operation without excessive air cooling demands, marking an early application of liquid cooling in commercial mainframes.

Virtual Addressing Developments

The Dynamic Address Translation (DAT) hardware in the IBM System/370 provided a foundational mechanism for virtual addressing, enabling the translation of 24-bit virtual addresses to real addresses through a two-level hierarchy of tables. This system utilized segment tables, each containing up to 256 entries of 4 bytes, to map 1 MB segments, with the segment-table origin stored in control register 1. Each segment entry pointed to a page table containing up to 256 entries of 2 bytes, mapping 4 KB pages to real page frames, while a translation lookaside buffer with 128 entries accelerated repeated translations by caching recent mappings. Introduced as a standard feature in the initial 1972 System/370 models, such as the Models 145, 158, 165 II, and 168, DAT supported up to 16 MB of virtual storage per address space while real memory configurations started at a minimum of 0.5 MB, scalable to higher capacities depending on the model. These models operated in Extended Control (EC) mode, where the translation mode bit in the Program Status Word activated DAT, allowing programs to reference virtual storage independently of physical constraints. Entry-level models like the 115, introduced in 1973 and supporting Basic Control (BC) mode for System/360 compatibility as well as EC mode, included standard DAT hardware for virtual storage capabilities up to 16 MB, with real memory limited to installed capacity. Similarly, the Model 125, announced in 1972 with deliveries in 1973, provided up to 16 MB virtual storage alongside real memory options of 98 KB or 131 KB, marking a key entry-level expansion of these features. This virtual addressing advancement significantly enhanced multiprogramming by permitting multiple jobs to execute concurrently in isolated virtual address spaces without requiring contiguous real memory allocation, thereby reducing overhead from swapping and improving overall system throughput in environments like OS/VS2. For instance, it enabled up to 63 problem program regions, fostering efficient resource sharing among tasks.

Post-Initial Enhancements

Following the initial System/370 implementations in the early 1970s, IBM introduced enhanced models in 1975 and 1977 that significantly improved processing speeds and efficiency. The System/370 Model 158-3, announced in August 1975, featured a CPU cycle time of 115 nanoseconds and delivered 20-50% faster instruction execution in basic control (BC) mode compared to the Model 155, with the Model 3 variant offering an additional 5-11% performance gain over the base Model 158 through expanded high-speed buffering (up to 16K bytes) and improved instruction prefetching. Similarly, the System/370 Model 168-3, released in 1977, reduced the CPU cycle time to 80 nanoseconds and achieved 10-30% higher performance than the Model 165 in BC mode, incorporating pipelined execution that prepared up to four instructions while executing one, along with doubleword fetching every cycle to enhance throughput. These models, reported to reach up to 2.45 MIPS in commercial workloads, also included larger translation lookaside buffers (128 entries) to accelerate virtual address translation, building on the foundational virtual addressing while prioritizing hardware-level optimizations for multiprogramming and I/O overlap. In the 1980s, the 303x series represented a major leap in System/370 hardware capabilities, with the IBM 3033 Processor Complex, announced in March 1977 but widely deployed through the early 1980s, featuring a 58-nanosecond cycle time, 64K-byte buffer storage, and performance 1.6 to 1.8 times that of the Model 168-3, enabling up to approximately 30 MIPS in high-end configurations like the later 308x variants within the series. These enhancements included firmware-based System/370 Extended features that improved control program efficiency by 14% in uniprocessor setups, along with denser monolithic main memory and reduced power consumption (about 30% less than the 168 series). An optional vector processing capability, provided via the attached 3838 Array Processor for compatible 303x systems, supported pipelined vector arithmetic at 100-nanosecond cycles for compute-intensive tasks such as seismic data processing, with memory capacities from 256K to 1M bytes to accelerate array operations without altering the core scalar instruction set. A key architectural upgrade in 1982 was the introduction of the Extended Control Program Support for VM (ECPS:VM), a hardware-assisted facility comprising 35 functions to optimize hypervisor operations in VM/370 environments on System/370 machines. This included enhancements to the Virtual Machine Assist (VMA) with 13 dedicated functions for faster simulation of guest instructions, I/O handling, and interval timer maintenance, reducing overhead for virtual machine management and enabling more efficient multiplexing of resources across multiple guests. Integrated with emerging dual-address-space support, ECPS:VM allowed hypervisors to switch between primary and secondary address spaces—each up to 16MB—facilitating better isolation and performance for concurrent workloads without full context switches, as part of the transitional facilities leading into System/370 Extended Architecture. In 1984, the Extended Real Addressing (ERA) feature extended System/370's physical memory addressing to support up to 16MB of real storage directly, eliminating paging overhead for real-mode programs and improving efficiency in environments with large contiguous data requirements. This upgrade, available on models like the 4381 processor complex, leveraged 26-bit real addressing to access the full 16MB without dynamic translation for non-virtualized tasks, enhancing throughput for database and scientific applications while maintaining compatibility with existing 24-bit limits in virtual modes.

Models and Variants

Chronological Introduction of Models

The IBM System/370 family evolved through a series of models released from 1970 to the mid-1980s, each building on the core architecture while incorporating advancements like virtual storage, improved memory technologies, and enhanced I/O capabilities to meet growing computational demands in commercial and scientific applications. This chronological overview highlights key releases tied to technological milestones, such as the shift to silicon memory in 1970 and the introduction of standard virtual addressing in 1972, culminating in extended architecture compatibility by 1985. The table below summarizes representative models, focusing on their introduction and withdrawal dates, performance in approximate MIPS (based on historical benchmarks for commercial workloads), memory ranges, and distinguishing features.
Model NumberIntroduction YearWithdrawal DatePerformance (MIPS)Memory Range (Real/Virtual)Key Features
155197019771256 KB–2 MB / Up to 16 MBInitial high-end model with core memory and optional dynamic address translation (DAT) for virtual storage; supported multiprocessing and backward compatibility with System/360.
165197019772.5512 KB–3 MB / Up to 16 MBHigh-performance variant with high-speed multiply option and buffer storage; DAT upgrade available for virtual addressing milestone in early 1970s computing.
145197019770.5128 KB–1 MB / Up to 16 MBEntry-level model introducing monolithic silicon memory chips, replacing ferrite cores; microprogrammed control for compatibility and error retry.
1951970197781 MB–4 MB / None initiallyTop-end scientific model with 16-way interleaved memory and no standard virtual support; focused on high-speed floating-point operations.
135197119800.8128 KB–512 KB / Up to 16 MBMidrange commercial model with standard virtual storage via DAT; integrated I/O and error-correcting code (ECC) memory.
158197219803512 KB–6 MB / Up to 16 MBMidrange with standard virtual storage and multiprocessing support; milestone in enabling OS/VS2 for larger address spaces. (Note: Used for announcement date confirmation via primary IBM context)
1681972198051 MB–8 MB / Up to 16 MBFlagship high-end model with high-speed buffer and extended virtual storage; supported attached processors for performance scaling.
115197319810.164 KB–256 KB / Up to 16 MBEntry-level with MOSFET memory and virtual support; integrated communications for time-sharing.
138197619831.5512 KB–1 MB / Up to 16 MBReplacement for 135 with extended control storage and improved channel performance; MOSFET upgrades for reliability.
30331977198574 MB–16 MB / Up to 16 MBHigh-end with integrated channels and 64 KB buffer; milestone in vector processing precursors and expanded I/O (up to 256 channels). (Note: Extended for 303x context)
30811980198768 MB–16 MB / Up to 2 GBBipolar processor with water cooling option; introduced high-reliability features like enhanced dynamic reconfiguration.
30901985199422 (up to 52 MP)128 MB–256 MB / Up to 2 GBCompatible extension with ESA/370 support, vector facility, and optical memory options; tied to 1980s milestone in scalable multiprocessing and 32-bit addressing expansions. (Note: For ESA/370 announcement) (Note: For performance context)

Grouped Model Specifications

The IBM System/370 models were organized into numbering groups that reflected their performance tiers and target applications, with the 100-series serving entry-level needs, the 130- and 140-series addressing mid-range computing, the 150- and 160-series providing high-end capabilities, and the 190-series focusing on scientific workloads. These groups shared the core System/370 architecture but varied in memory capacity, logic technology, and integrated features to optimize cost and performance for specific environments.

100-Series (Models 115 and 125)

The 100-series models were designed as low-end, compact systems emphasizing emulation of earlier IBM architectures and integrated I/O for small-scale data processing, suitable for business applications with limited budgets. These models utilized MOSFET technology for main memory and featured a distributed-processor architecture with subprocessors for instruction processing, storage control, and I/O operations. They supported Basic Control (BC) and Extended Control (EC) modes, with emulation of the System/360 Model 20 via microprogrammed interpretive execution, enabling compatibility with legacy software while introducing virtual storage capabilities under DOS/VS. Configurations were cardless and space-efficient, often including an integrated console and direct attachments for disks and tapes without requiring separate channel interfaces. Key specifications for the 100-series are summarized below:
ModelMain Memory CapacityCycle TimeKey Features
11565 KB to 196 KB480 ns (read/write)Machine Instruction Processor (MIP); up to 3 integrated channels (pseudo-multiplexer, direct disk, tape); Integrated Communications Adapter (up to 12 subchannels); 3340 disk support (up to 1.8 GB total); System/360 Model 20 emulation; automatic error correction.
12598 KB to 512 KB480 ns (read/write); 320 ns (Model 125-2)CRT console; integrated 3330/3340 disk control; up to 2.4 GB disk storage; 20-30% performance improvement in enhanced version; no buffer memory; supports VSPC with minimum 256 KB.
These models offered approximately 55-75% better performance than initial configurations through enhancements like expanded memory and integrated adapters, prioritizing reliability in decentralized designs with minimal subprocessor interference.

130/140-Series (Models 135, 138, 145, and 148)

The 130- and 140-series represented mid-range systems optimized for commercial and scientific workloads, incorporating integrated circuit (IC) logic via Monolithic Systems Technology (MST) for improved density and speed over prior core-based designs. These models supported virtual storage with Dynamic Address Translation (DAT) and a Translation Lookaside Buffer (TLB) for efficient addressing, alongside optional floating-point units and block multiplexer channels. The 130-series focused on cost-effective tape and disk systems, while the 140-series emphasized expanded I/O and emulation for legacy environments like 1401/1440 systems. They used a mix of bipolar LSI and MOSFET technologies, enabling up to 256 subchannels and integrated file adapters for versatile configurations. Key specifications for the 130/140-series are summarized below:
ModelMain Memory CapacityCycle TimeKey Features and Performance
135128 KB to 512 KB770 ns (read); 935 ns (write)Bipolar LSI; integrated disk/tape control; 2-4.5x performance of System/360 Model 30 (commercial); supports VM/370; no buffer memory; 128 KB control store.
138512 KB to 1 MB710-770 ns (read); 935 ns (write)MOSFET; 29-36% faster than Model 135; 128 KB reloadable control store; VS APL assists; tape/disk system; 1.18-1.38x batch throughput vs. 135.
145164 KB to 2 MB540 ns (fetch); 607.5 ns (store)All-semiconductor memory (first in System/370); MST IC logic; 3-5x System/360 Model 40; byte multiplexer (up to 256 subchannels); 32-64 KB control storage; 1401/1410 emulation; up to 5 MB/s aggregate I/O.
1481 MB to 2 MB405 ns (read); 540 ns (write)MOSFET; 28-43% faster than Model 145; four block multiplexer channels; 3350 disk support; integrated file adapter; 128 KB control store.
Performance in this series benefited from features like error-correcting code (ECC) and microinstruction retry, with the Model 145 introducing monolithic storage array chips (128 bits each) for compact, reliable operation.

150/160-Series (Models 155, 158, 165, and 168)

The 150- and 160-series comprised high-end models for demanding enterprise applications, featuring water-cooled processors in higher configurations for thermal management during intensive operations, along with support for multiprocessing and high I/O throughput. These systems initially used magnetic core memory but transitioned to semiconductor technologies, with standard floating-point execution and buffer storage to reduce access latency. Virtual storage was addable via DAT, enabling up to 16 MB per address space, and they supported tightly coupled multiprocessing through units like the 3068. The series emphasized scalability, with up to 64 disk drives and aggregate I/O rates exceeding 16 MB/s in advanced setups. Key specifications for the 150/160-series are summarized below:
ModelMain Memory CapacityCycle TimeKey Features and Performance
155256 KB to 2 MB2.07 µs (core); 115 ns (buffer)Magnetic core; 3.5-4x System/360 Model 50; 8-32 KB buffer; up to 5.4 MB/s I/O; no initial virtual storage; four-way interleaving.
158512 KB to 6 MB115 ns (CPU); 690-1035 ns (read, Model 1); 920 ns (Model 3)MOSFET; 20-40% faster than Model 155; 8-16 KB high-speed buffer; up to 6.75 MB/s I/O; 128-entry TLB; integrated storage controls for 64 drives; multiprocessing option.
165512 KB to 3 MB2 µs (core); 80 ns (buffer)Magnetic core; 2-5x System/360 Model 65; 8-32 KB buffer; up to 8 MB/s I/O; high-speed multiply; water-cooled in higher configs; four-way interleaving.
1681 MB to 8 MB80 ns (CPU)MOSFET; 10-30% faster than Model 165; 8-32 KB buffer; up to 17 MB/s aggregate I/O; water-cooled CPU; 128-entry TLB; dual-channel I/O bus; supports 16 MB virtual per machine; multiprocessing with 3068 unit.
Enhancements like Virtual Machine Assist reduced overhead in VM/370 environments, and water-cooling via the 3067 unit ensured stability in multi-CPU setups.

190-Series (Model 195)

The 190-series, exemplified by the Model 195, targeted scientific computing with vector processing extensions and ultra-high-speed execution, positioning it as IBM's flagship for compute-intensive tasks like simulations and large-scale calculations. It employed magnetic core memory with 16-way interleaving for parallel access and lacked initial virtual storage support, focusing instead on raw performance through specialized floating-point hardware capable of concurrent operations. The design included high I/O rates via multiple channels and buffer storage, making it suitable for environments requiring up to twice the speed of the System/360 Model 85. Optional features like extended precision floating-point further enhanced its utility for numerical workloads. Key specifications for the 190-series are summarized below:
ModelMain Memory CapacityCycle TimeKey Features and Performance
1951 MB to 4 MB756 ns (read/write)Magnetic core; no initial virtual storage; 8-32 KB buffer; 16-way interleaving; high-speed floating-point (up to three operations concurrently); up to 9 MIPS; ultra-high I/O (multiple selector channels); withdrawn by 1977.
The Model 195's architecture prioritized concurrency in the floating-point unit, establishing it as a precursor to specialized vector systems while maintaining System/370 compatibility.

Compatible and Cloned Systems

The Amdahl Corporation introduced the 470V series in 1975 as the first major third-party mainframe designed to be fully compatible with the IBM System/370 architecture, offering performance comparable to IBM's high-end models like the 370/168 while providing lower costs and higher reliability. The 470V systems achieved complete functional compatibility with the System/370 instruction set and IBM's OS/360 and OS/370 software environments, allowing seamless migration for users without software modifications. This compatibility was a deliberate design choice by Amdahl founder Gene Amdahl, a former IBM executive, to challenge IBM's dominance in the mainframe market. Other vendors followed with System/370-compatible systems, including Hitachi's HITAC M Series in Japan, which conformed to the System/370 architecture to meet the needs of domestic users reliant on IBM software. Hitachi's M Series processors were engineered for direct compatibility with System/370 peripherals and operating systems, enabling Japanese organizations to adopt cost-effective alternatives while maintaining interoperability. Similarly, National Semiconductor, through its Exsysco subsidiary, developed the AS/5 and related models in the late 1970s, emulating System/370 Models 138, 148, and 158 with 100% functional compatibility to the IBM instruction set and software stack. These systems were marketed under brands like Itel Advanced Systems, targeting mid-range users seeking affordable entry into the System/370 ecosystem. In addition to full-system clones, plug-compatible manufacturers (PCMs) produced peripheral devices that interfaced directly with System/370 mainframes, such as disk drives and tape units from companies like Memorex and Storage Technology Corporation, which undercut IBM's prices without requiring system redesigns. These peripherals adhered to System/370 channel interfaces, allowing users to mix vendor components for cost savings while preserving overall system integrity. The rise of these compatible and cloned systems was significantly influenced by antitrust litigation against IBM in the 1970s and 1980s, including the U.S. Department of Justice's 1969 monopoly case and private suits like Telex Corp. v. IBM (1970) and Memorex Corp. v. IBM (1977), which challenged IBM's predatory pricing and bundling practices that hindered third-party competition. These cases, many of which resulted in rulings favoring PCMs, opened the market by restraining IBM's ability to leverage its dominance, thereby fostering an environment where clones like Amdahl's and Hitachi's could thrive and capture significant market share during the decade. The DOJ suit, dismissed in 1982, ultimately contributed to a more competitive landscape without breaking up IBM, as clones eroded its monopoly through innovation and lower pricing.

Architecture

Instruction Set Architecture

The IBM System/370 instruction set architecture (ISA) builds upon the System/360 foundation, providing a comprehensive set of instructions for fixed-point, floating-point, decimal, and logical operations, while introducing enhancements for control and compatibility. It features 16 general-purpose registers (GPRs), each 32 bits wide, designated as R0 through R15, which serve as both arithmetic operands and address pointers in non-indexed modes. Additionally, there are four 64-bit floating-point registers, numbered 0, 2, 4, and 6 (with even numbers only), supporting short, long, and extended precision formats for scientific and engineering computations. Instructions in the System/370 ISA are encoded in variable-length formats, with three primary types: RR (register-to-register), RX (register-and-indexed-storage), and RS (register-and-storage). The RR format, a single halfword long, specifies two operands in registers R1 and R2, as seen in the Add Register (AR) instruction (opcode 1A), which adds the contents of R2 to R1. The RX format spans two halfwords, including an opcode, R1, an index register X2, a base register B2, and a 12-bit displacement D2 for effective address calculation; for example, the Load (L) instruction (opcode 58) fetches a 32-bit word from storage into R1 using the address formed by X2 + B2 + D2. The RS format also uses two halfwords, specifying R1, R3, B2, and D2, and supports operations like shifts or branches, such as the Shift Left Arithmetic (SLA) instruction (opcode 8B). These formats enable efficient register-based and memory-access operations while maintaining backward compatibility with System/360 software. The architecture operates in two execution modes—problem state and supervisor state—to enforce privilege separation, determined by bit 15 of the Program Status Word (PSW): 1 for problem state (restricted user-mode access) and 0 for supervisor state (full system privileges). Privileged instructions, such as Load PSW (LPSW), which replaces the current PSW with a new one from a specified storage location to alter the instruction address, condition code, and mode, are suppressed in problem state to prevent unauthorized control changes. Basic control instructions like Load Control (LCTL), which transfers contents from storage to control registers, further manage system status transitions. Introduced with the initial System/370 models in 1970, the Basic Control feature provided the core ISA, including a PSW format compatible with System/360 and support for decimal instructions such as Add Decimal (AP, opcode 5A) for packed decimal arithmetic. The Extended Control (EC) feature, introduced with System/370 in 1970 (with full implementation in models from 1972), expanded this with additional control registers, program-event recording for debugging, and enhancements to decimal instructions, including Sign Rounded Pack (SRP) for precise decimal manipulation and Zero Add Packed (ZAP) for initialization, improving commercial data processing efficiency. These extensions ensured upward compatibility while addressing evolving requirements for control and arithmetic operations.

Memory and Addressing Features

The IBM System/370 employs 24-bit real addressing, enabling direct access to up to 16 megabytes of main storage, which is byte-addressable to support granular data manipulation at the 8-bit level. This addressing scheme maps virtual or logical addresses to physical locations without translation when dynamic address translation (DAT) is disabled, ensuring efficient handling of contiguous storage blocks, such as the 2,048-byte units used in certain storage key operations. In multiprocessing configurations, real addressing incorporates prefixing to reassign low-order real address blocks (0-4,095) for isolation between processors. Virtual addressing in the System/370 extends to a 24-bit space of up to 16 megabytes per address space, allowing programs to operate in a logical view of memory independent of physical constraints. DAT, enabled by bit 5 of the program status word (PSW) in extended control (EC) mode, performs this mapping through a two-level hierarchy of segment and page tables designated by control registers 0 and 1. In base System/370, the 24-bit virtual address (formatted in bits 0-31 with bits 0-7 zero) is divided into a segment index (bits 8-11, selecting one of up to 16 segments), a page index within the segment (bits 12-19, selecting one of 256 pages), and byte offset (bits 20-31). Note that segment and page sizes can vary per control register 0 settings, affecting bit positions (e.g., for 64 KB segments, segment index is bits 8-15). Segment tables organize the virtual space into fixed-size units (1 MB or 64 KB depending on control register 0 bits 11-12), with each entry (4 bytes) specifying the origin and length of a corresponding page table, along with an invalid bit for access control. Page tables then subdivide each segment into pages (4 KB or 2 KB depending on control register 0 bits 8-9), with entries (4 bytes) providing the real page frame address and an invalid bit to enforce protection and manage paging. Control register 0 bits 8-9 and 11-12 determine page and segment sizes, respectively, while the translation lookaside buffer (TLB) caches recent mappings to accelerate subsequent accesses; instructions like Set Prefix (SPX) invalidate the TLB during address space switches. Address space control in the base System/370 architecture limits operations to a single 16-megabyte virtual space per execution environment, managed via PSW and control registers to enable DAT and protect storage through keys and invalid bits. In later extensions under System/370 Extended Architecture (370-XA), the Address Space Number (ASN)—a 16-bit identifier—supports up to 65,536 distinct 2-gigabyte virtual address spaces, stored in control registers 3 and 4 for primary and secondary spaces, respectively. ASN translation uses a two-level table (ASN-first and ASN-second) for designation of segment tables and linkage parameters, with instructions like Set Secondary ASN (SSAR) and Extract Primary ASN (EPAR) facilitating secure space switching and authorization checks via an authority table. Exceptions such as primary-authority or ASN-translation faults ensure isolation, storing the offending ASN in low real storage for diagnosis. To enhance memory access performance, System/370 models from the mid-1970s incorporated high-speed buffer storage, functioning as an on-chip cache for instructions and data. In 1980s models like the 3081 Processor Complex, this evolved into explicit cache units, with each central processor featuring a 64-kilobyte cache providing two-cycle access to eight-byte blocks, integrated with DAT for transparent high-speed buffering. This two-level storage hierarchy—cache plus main memory—reduced average access times, bridging the speed gap between processor and bulk storage while maintaining compatibility with earlier buffer implementations.

Channel-Based I/O System

The IBM System/370 channel-based I/O system offloads input/output operations from the central processing unit (CPU), enabling concurrent execution of data processing and I/O activities to enhance overall system efficiency. Channels serve as intelligent controllers that manage data transfers between main storage and peripheral devices via control units, using a standardized interface that supports asynchronous operations and interruption mechanisms for status reporting. This architecture, detailed in the System/370 Principles of Operation, emphasizes reliability through features like subchannel management for tracking multiple concurrent operations and protection keys to secure access to storage areas. The System/370 I/O subsystem evolved from the System/360 design by preserving full compatibility with existing peripherals and interfaces while introducing the block-multiplexer channel in 1972 to support higher throughput for medium- to high-speed devices through interleaved block transfers. Unlike the System/360's primary reliance on byte-multiplexer and selector channels, the System/370 standardized block mode operations across models, allowing channels to alternate between burst transfers for single high-speed devices and multiplexed subchannel access for multiple devices, thereby reducing CPU intervention and improving resource utilization. This addition addressed growing demands for multitasking environments, with subchannels providing dedicated status and control for up to 256 devices per channel in later configurations. System/370 channels are categorized into three types, each optimized for specific device speeds and concurrency needs: byte-multiplexer channels for low-speed, multi-device environments; block-multiplexer channels for balanced high-speed multiplexing; and selector channels for dedicated high-speed sequential access. Byte-multiplexer channels operate in byte-interleave mode to handle simultaneous low-speed devices like line printers or card readers, prioritizing based on response times and supporting up to 256 subchannels, with data rates typically around 25,000 to 29,000 bytes per second in burst mode for faster attachments. Block-multiplexer channels, introduced to merge selector-like efficiency with multiplexing, enable interleaved operations across multiple subchannels for devices such as disk drives, allowing burst mode for high-rate transfers and optional multiplexing controlled via register settings, which significantly boosts throughput in shared environments. Selector channels, suited for high-speed peripherals like tape units, connect to a single device at a time in burst mode without interleaving, ensuring maximum data rates—up to several megabytes per second—by dedicating the full channel bandwidth to one operation until completion. All channel types use the same command formats and interface protocols, with integrated or independent implementations depending on the model. I/O operations in the System/370 are initiated and managed through three primary CPU instructions: Start I/O (SIO), Test I/O (TIO), and Halt I/O (HIO). The SIO instruction fetches the channel address word (CAW) from main storage to select a device and initiate command chaining via channel command words (CCWs), supporting features like indirect data addressing for noncontiguous buffers and fast release to minimize CPU wait times. TIO examines the status of pending or active operations, optionally storing the channel status word (CSW) and clearing interruptions to allow polling without full initiation. HIO terminates an ongoing I/O immediately, useful for error recovery or priority shifts, by signaling the channel to halt and report status. These instructions, executed in either basic control (BC) or extended control (EC) mode, integrate with the program status word (PSW) for interruption handling and control register 0 for channel masks, ensuring serialized access in multiprocessor setups. In the 1980s, the channel-based I/O system received enhancements through the Enterprise Systems Connection (ESCON) architecture, a fiber optic serial interface introduced in 1988 that extended compatibility to System/370 control units via ESCON converters. ESCON replaced parallel copper cabling with optical links supporting distances up to 9 kilometers, dynamic switching through directors with up to 60 ports, and non-synchronous protocols for reduced latency in large-scale I/O configurations, while maintaining electrical compatibility for legacy System/370 devices. This upgrade facilitated migration to newer processors without replacing existing peripherals, preserving the core channel principles of subchannel management and interruption-driven operations.

Software Ecosystem

Operating Systems Support

The IBM System/370 supported a range of operating systems that built upon the software foundation of its predecessor, the System/360, while introducing enhancements for virtual storage to leverage the architecture's new memory management capabilities. These systems were designed to handle increasing demands for multitasking, larger memory addressing, and efficient resource allocation in enterprise environments. The primary operating systems included variants optimized for different system sizes and workloads, with a clear migration path toward more advanced multitasking environments. Additionally, TSS/370 provided time-sharing capabilities in a virtual storage environment but saw limited adoption and was discontinued in 1982. Building on the OS/360 family, the Virtual Storage (VS) series introduced more sophisticated memory management. OS/VS1, released in 1972 as a virtual storage extension of OS/MFT, was designed for single virtual storage environments and supported up to 15 user partitions with job entry subsystem (JES) integration for streamlined batch operations. It required a minimum of 160 KB of memory and emphasized storage protection and fetch mechanisms, making it suitable for mid-range System/370 models. OS/VS2, also released in 1972, evolved from OS/MVT and initially operated in single virtual storage (SVS) mode, supporting up to 63 initiators and requiring at least 384 KB of memory; later releases added multiprocessor support, allowing efficient operation across multiple CPUs on larger System/370 configurations. For smaller System/370 installations, DOS/VS provided a lighter-weight alternative, released in 1972 as a virtual storage upgrade to the Disk Operating System (DOS) from the System/360 era. It supported up to seven concurrent jobs in a virtual environment with 16 MB addressing, including spooling via the POWER subsystem, and was targeted at entry-level models like the 370/115 with minimal hardware requirements starting at 90 KB of real memory for batch processing. This system facilitated online transaction processing and was particularly useful for organizations transitioning from older DOS-based setups without needing the full complexity of OS/VS. VM/370, introduced in 1972, offered virtualization capabilities by creating multiple virtual machines on a single physical System/370, each running independent operating systems such as OS/VS1, OS/VS2, or DOS/VS. It utilized the System/370's virtual storage features to allocate up to 16 MB per virtual machine, enabling time-sharing through the Conversational Monitor System (CMS) and supporting diverse workloads like testing and development in isolated environments. This control program enhanced system efficiency by partitioning resources dynamically, particularly on models like the 370/158. A key aspect of the System/370 software ecosystem was the migration path to MVS/370, which emerged in 1974 as OS/VS2 Release 2 and represented a significant advancement in multiple virtual storage (MVS). MVS/370 provided separate 16 MB address spaces for each job or subsystem, improving isolation and scalability for high-volume transaction processing; it included advanced features like JES2/JES3 for job scheduling, Time Sharing Option (TSO) for interactive access, and VSAM for file management. Users of OS/360, VS1, and VS2 could migrate to MVS/370 with relative ease due to backward compatibility, allowing gradual upgrades to support growing enterprise needs throughout the 1970s. This progression underscored the System/370's role in enabling long-term software evolution toward more robust, virtualized computing.

Programming and Development Tools

The IBM System/370 relied on a suite of programming tools optimized for its virtual storage architecture, enabling developers to create efficient applications in assembly and high-level languages. Central to low-level programming was Assembler H, an advanced assembler language processor introduced with OS/VS, which extended the capabilities of earlier System/360 assemblers to support the full range of System/370 instructions, including those for virtual addressing and dynamic address translation. Assembler H provided high-speed assembly with comprehensive macro facilities, allowing programmers to define and nest macros for code generation, conditional assembly based on symbolic parameters, and integration with system macros for input/output operations, thereby streamlining the development of system-level software and device drivers. These features made it indispensable for optimizing performance in environments with limited real memory, as macros reduced redundant code and facilitated modular programming. High-level language support was provided through compilers tailored for virtual storage environments, starting with OS/VS FORTRAN, which compiled standard FORTRAN IV programs into relocatable object modules that leveraged System/370's virtual addressing to manage large datasets without fixed partitioning constraints. This compiler incorporated optimizations such as common subexpression elimination and loop unrolling, enabling efficient execution under OS/VS1 and MVS by aligning code with the hardware's paging mechanisms and reducing page faults in scientific and engineering applications. Similarly, OS/VS COBOL supported business-oriented programming with features for virtual storage, including dynamic storage allocation for working-storage sections and optimized table handling that minimized I/O overhead in transaction processing. The compiler generated code compatible with System/370's extended control program facilities, ensuring seamless integration with virtual I/O channels for file operations. For versatile application development, the OS PL/I Optimizing Compiler offered robust support for structured programming in a virtual storage context, with optimizations like inline expansion of procedures and automatic storage management that exploited System/370's address space extensions to handle complex data structures without manual relocation. This compiler's ability to produce reentrant code facilitated multitasking under OS/VS, making it suitable for both batch and interactive workloads. In the 1990s, as interest in emulating System/370 environments grew, efforts extended to porting modern tools like the GNU Compiler Collection (GCC) to the architecture, with David Pitts developing a port that targeted the IBM High Level Assembler (HLASM) for generating System/370-compatible object code. This port supported C and other languages, enabling cross-compilation from Unix-like systems to System/370 binaries for legacy software maintenance and experimentation on emulators, though it required adaptations for EBCDIC character handling and virtual storage conventions. Early cross-compilers, such as those based on this work, allowed developers to build and test code remotely without direct access to physical hardware. Debugging System/370 software was facilitated by tools like the Interactive Problem Control System (IPCS), introduced with OS/VS2 MVS, which provided an online facility for analyzing dumps and trace data from virtual storage failures. IPCS enabled interactive examination of control blocks, symbol tables, and memory contents using commands to format System/370-specific structures, such as page tables and channel status words, aiding in the diagnosis of OS/VS-related issues like abends or storage violations. By integrating with the operating system's problem management, it streamlined post-mortem analysis and report generation for production environments.

Successors and Legacy

Transition to System/390

Following the base System/370, the System/370 Extended Architecture (370-XA) in 1983 and ESA/370 extended the architecture, leading to the announcement of the Enterprise Systems Architecture/390 (ESA/390) by IBM in September 1990, positioning it as the direct successor to the System/370 family and marking the end of new base System/370 development. Building on 370-XA, which introduced 31-bit addressing that expanded real memory capacity to 2 GB (2³¹ bytes) from the 16 MB limit of earlier 24-bit addressing modes—controlled by the program status word (PSW) bit 32, enabling bimodal operation for both 24-bit and 31-bit modes to support legacy and new applications—ESA/390 provided key enhancements, including an expanded instruction set with new facilities such as immediate-and-relative instructions (e.g., ADD HALFWORD IMMEDIATE), linkage instructions (e.g., PROGRAM CALL and BRANCH AND STACK), and I/O commands (e.g., START SUBCHANNEL and RESUME SUBCHANNEL), facilitating more efficient program management and data processing. Backward compatibility was a cornerstone of the design, ensuring that all System/370 hardware models and software could operate on ESA/390 systems either directly or through emulation modes, with problem-state programs from System/370 requiring minimal or no modification. This compatibility extended to control programs via specific control-register settings and preserved System/370 interfaces for I/O operations, protecting customer investments in existing applications. The transition to System/390 was phased to minimize disruption, with ongoing support for the last System/370 models—such as the high-end 3090—continuing into the mid-1990s to allow gradual migration.

Enduring Impact and Modern Relevance

The IBM System/370's instruction set architecture served as the foundational basis for subsequent mainframe evolutions, culminating in the 64-bit z/Architecture implemented in IBM z Systems, which maintains full backward compatibility with System/370 software and hardware interfaces. This lineage traces directly from the System/360 through the System/370, System/370-XA, ESA/370, ESA/390 to z/Architecture, enabling seamless execution of legacy code on modern processors like the IBM z17 introduced in 2025. The enduring design principles of virtual storage, multitasking via interrupts, and dynamic address translation from the System/370 continue to underpin z/Architecture's support for operating systems such as z/OS, Linux, and z/TPF, ensuring scalability for high-volume transaction processing. Emulation technologies have preserved the System/370's accessibility for education, research, and hobbyist use on contemporary platforms. The open-source Hercules emulator provides a complete software implementation of the System/370 architecture, allowing it to run on Linux systems and execute original operating systems like OS/370 without proprietary hardware. Developed and maintained by a community of contributors, Hercules supports not only System/370 emulation but also extensions to ESA/390 and z/Architecture, facilitating the booting and operation of historical software stacks such as MVS 3.8j under virtual machine environments on modern x86 or ARM-based Linux hosts. In sectors like finance and banking, System/370-era applications remain operational today through native compatibility on IBM z Systems hardware, processing billions of transactions annually without requiring full rewrites. For instance, over 800 banks rely on services supported by IBM z mainframes for core banking operations, leveraging the platform's reliability for mission-critical workloads that originated in the 1970s and 1980s. Where hardware upgrades are not feasible, emulation on modern servers enables continued support for these legacy systems, minimizing disruption in regulated environments. The System/370 profoundly shaped enterprise computing standards by establishing benchmarks for compatibility, reliability, and scalability that influenced the broader IT industry. Its architecture, an extension of the System/360 family, introduced virtual memory and multiprogramming concepts that became de facto norms for large-scale data processing, enabling the shift from batch-oriented to interactive systems in business environments. This durability fostered a cultural emphasis on backward compatibility in enterprise IT, where the System/370's design principles continue to inform standards for secure, high-availability computing in global organizations.

References

  1. https://www.ibm.com/history/system-370
  2. https://bitsavers.computerhistory.org/pdf/ibm/370/systemSummary/GA22-7001-4_370_System_Summary_Dec75.pdf
  3. https://www.nytimes.com/1970/07/01/archives/ibm-shows-2-new-computers-ibm-shows-2-new-computer-models.html
  4. https://bitsavers.org/pdf/ibm/370/systemGuide/GC20-1730-0_370-165_Guide_Nov70.pdf
  5. http://www.bitsavers.org/pdf/ibm/370/VM/370/GR20-4260-1_Introduction_To_Virtual_Storage_In_System_370_Feb73.pdf
  6. https://www.ibm.com/docs/en/zos-basic-skills?topic=storage-brief-history-virtual-64-bit-addressability
  7. https://dl.acm.org/doi/10.1145/359327.359337
  8. https://www.cs.tufts.edu/comp/150FP/archive/alfred-spector/spector87ibm.pdf
  9. https://bitsavers.org/pdf/ibm/370/systemSummary/GA22-7001-6_370_System_Summary_Dec76.pdf
  10. https://bitsavers.org/pdf/ibm/370/funcChar/GA33-1510-0_370-115_funcChar_Mar73.pdf
  11. https://bitsavers.computerhistory.org/pdf/datapro/datapro_reports_70s-90s/IBM/70C-491-05_7308_IBM_System_370.pdf
  12. https://gunkies.org/wiki/IBM_System/370
  13. https://bitsavers.computerhistory.org/pdf/datapro/datapro_reports_70s-90s/IBM/70C-491-05_7211_IBM_System_370_Model_125.pdf
  14. https://www.ithistory.org/db/hardware/ibm/ibm-system370-model-125
  15. https://ed-thelen.org/comp-hist/IBM-ProdAnn/370-145.pdf
  16. https://bitsavers.org/pdf/ibm/370/systemGuide/GC20-1734-2_370-145_Guide_Aug72.pdf
  17. https://www.ithistory.org/db/hardware/ibm/ibm-system370-model-135
  18. http://www.righto.com/2021/01/ibm-paperweight-teardown-reverse.html
  19. https://bitsavers.trailing-edge.com/pdf/ibm/370/systemGuide/GC20-1755-2_370-168_Guide_Jun75.pdf
  20. http://www.bitsavers.org/pdf/datapro/datapro_reports_70s-90s/IBM/70C-491-04_7503_IBM_System_370.pdf
  21. https://bitsavers.trailing-edge.com/pdf/ibm/370/funcChar/GA24-3557-3_IBM_370_Model_145_Functional_Characteristics_Aug72.pdf
  22. http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/370/princOps/GA22-7000-4_370_Principles_Of_Operation_Sep75.pdf
  23. http://ftpmirror.your.org/pub/misc/bitsavers/pdf/datapro/datapro_reports_70s-90s/IBM/70C-491-04_7303_IBM_System_370.pdf
  24. https://people.computing.clemson.edu/~mark/ExploringInnovativeCoolingSolutions.pdf
  25. http://www.bitsavers.org/pdf/ibm/370/systemGuide/GC20-1734-2_370-145_Guide_Aug72.pdf
  26. https://sharktastica.co.uk/resources/docs/pdf/IBM_GA22-7001-6_S370-Processor-Summary_1976_bitsavers.pdf
  27. https://bitsavers.org/pdf/ibm/370/model158/GC20-1754-2_A_Guide_to_the_System_370_Model_158_3rd_ed_197508.pdf
  28. http://www.roylongbottom.org.uk/mips.htm
  29. https://bitsavers.org/pdf/datapro/datapro_reports_70s-90s/IBM/70C-491-04_7704_IBM_System_370.pdf
  30. https://www.vm.ibm.com/history/50th/s370eavm.pdf
  31. https://groups.google.com/g/alt.folklore.computers/c/bO0cwjQ2MLU
  32. https://www.computinghistory.org.uk/det/2224/ibm-370-138/
  33. https://www.nextplatform.com/2018/06/28/a-sea-change-coming-for-water-cooling-in-datacenters/
  34. https://www.tomshardware.com/picturestory/508-mainframe-computer-history-2.html
  35. https://bitsavers.trailing-edge.com/pdf/datapro/datapro_reports_70s-90s/IBM/70C-491-04_7704_IBM_System_370.pdf
  36. https://bitsavers.computerhistory.org/pdf/ibm/370/model158/GC20-1754-2_A_Guide_to_the_System_370_Model_158_3rd_ed_197508.pdf
  37. https://bitsavers.org/pdf/ibm/370/funcChar/GA22-7011-4_IBM_System_370_Model_158_Functional_Characteristics_197604.pdf
  38. https://bitsavers.computerhistory.org/pdf/ibm/370/funcChar/GA22-7010-4_370-168_funcChar_Jul76.pdf
  39. http://www.bitsavers.org/pdf/amdahl/datapro/70C-044-01_7709_Amdahl_470.pdf
  40. http://bitsavers.informatik.uni-stuttgart.de/pdf//amdahl/470/G1023.0-01A_Amdahl_470V_5-I_Machine_Reference_Manual_Jun79.pdf
  41. https://digital.library.unt.edu/ark:/67531/metadc282696/
  42. http://museum.ipsj.or.jp/en/computer/main/0039.html
  43. https://dspace.mit.edu/bitstream/handle/1721.1/48057/hitachipioneerinx00cusu.pdf?sequence=1
  44. https://www.nytimes.com/1979/02/04/archives/to-clone-a-computer-neophyte-national-semiconductor-has-jolted-the.html
  45. http://www.bitsavers.org/pdf/datapro/datapro_reports_70s-90s/Itel/70C-546-01_7612_Itel_Advanced_Systems.pdf
  46. https://digitalcommons.law.ggu.edu/cgi/viewcontent.cgi?referer=&httpsredir=1&article=1345&context=ggulrev
  47. http://ftpmirror.your.org/pub/misc/bitsavers/pdf/datapro/datapro_reports_70s-90s/_Survey_Index/70C-010-60_8001_All_About_Plug-Compatible_Mainframes.pdf
  48. https://www.justice.gov/atr/case-document/united-states-memorandum-1969-case
  49. https://www.cato.org/regulation/sept/oct-1985/system-error-how-ibm-antitrust-suit-raised-computer-prices
  50. https://www.historyofinformation.com/detail.php?id=923
  51. https://bitsavers.trailing-edge.com/pdf/ibm/370/princOps/GA22-7000-4_370_Principles_Of_Operation_Sep75.pdf
  52. http://bitsavers.org/pdf/ibm/370/princOps/GA22-7000-0_370_Principles_Of_Operation_Jun70.pdf
  53. https://bitsavers.org/pdf/ibm/370/princOps/SA22-7085-0_370-XA_Principles_of_Operation_Mar83.pdf
  54. ftp://ftpmirror.your.org/pub/misc/bitsavers/pdf/datapro/datapro_reports_70s-90s/IBM/70C-491-07_8202_IBM_3081.pdf
  55. https://bitsavers.org/pdf/ibm/370/funcChar/GA22-6942-1_370-155_funcChar_Jan71.pdf
  56. https://gunkies.org/wiki/IBM_I/O_channel
  57. https://bitsavers.org/pdf/ibm/390/brochures/GU20-0086_IBM_ESCON_Brochure.pdf
  58. https://www.jaymoseley.com/hercules/downloads/pdf/$OSTL33.pdf
  59. http://ftpmirror.your.org/pub/misc/bitsavers/pdf/datapro/datapro_reports_70s-90s/IBM/70C-491-04_8005_IBM_System_370.pdf
  60. https://bitsavers.computerhistory.org/pdf/ibm/370/VM/370/Release_6/GC20-1821-3_VM370_Operating_Systems_in_a_Virtual_Machine_Rel_6_PLC_17_Apr81.pdf
  61. https://bitsavers.org/pdf/ibm/370/asm/SC26-4036-2_Assembler_H_Version_2_Programming_Guide_Release_1_3rd_ed_198712.pdf
  62. https://share.confex.com/share/120/webprogram/Handout/Session12235/asmhisth.pdf
  63. https://bitsavers.trailing-edge.com/pdf/ibm/370/OS_VS/fortran/SC26-3985-2_VS_FORTRAN_Application_Programming_Guide_Jan82.pdf
  64. https://bitsavers.trailing-edge.com/pdf/ibm/370/OS_VS/cobol/GC26-3857-3_IBM_VS_COBOL_for_OS_VS_Rel_2.4_Aug83.pdf
  65. https://bitsavers.trailing-edge.com/pdf/ibm/370/pli/SC33-0006-7_OS_PLI_Optimizing_Compiler_Programmers_Guide_Sep85.pdf
  66. http://www.nyx.net/~dpitts/
  67. https://linas.org/linux/i370-bigfoot.html
  68. https://bitsavers.trailing-edge.com/pdf/ibm/370/OS_VS2/GC34-2006-1_OSVS2_MVS_Interactive_Problem_Control_System_Users_Guide_and_Reference_2nd_ed_197910.pdf
  69. https://publibfp.dhe.ibm.com/epubs/pdf/dz9ar008.pdf
  70. https://www.ibm.com/history/system-390
  71. https://www.ibm.com/docs/en/ztpf/1.1.2023?topic=support-zarchitecture-configuration
  72. https://techchannel.com/z-os/mainframe-architecture-then-and-now/
  73. https://newsroom.ibm.com/z17
  74. http://www.hercules-390.org/
  75. https://www.ibm.com/think/topics/mainframe-for-banking
  76. https://www.fintechweekly.com/magazine/articles/why-mainframes-still-matter-in-banking-digital-era-interview-with-jennifer-nelson
  77. https://cacm.acm.org/research/case-study-ibms-system-360-370-architecture/
  78. https://www.computerworld.com/article/1394715/the-mainframe-turns-50-or-why-the-ibm-system-360-launch-was-the-dawn-of-enterprise-it.html
Add your contribution
Related Hubs
User Avatar
No comments yet.