The IBM System/370 (often: S/370) was a model range of IBM mainframes announced on June 30, 1970 as the successors to the System/360 family. The series maintained backward compatibility with the S/360, allowing an easy migration path for customers; this, plus improved performance, were the dominant themes of the product announcement. New architectural features distinct from the S/360 range included: standard dual-processor capability; full support for virtual memory; and 128-bit floating point arithmetic.
Evolution
The original System/370 line underwent several architectural improvements during its roughly 20-year lifetime. The first and most significant change was the introduction of virtual memory, which was first made generally available in 1972 via IBM's "System/370 Advanced Function" announcement. IBM had initially (and controversially) chosen to exclude virtual storage from the S/370 line.
The August 2nd, 1972 announcement included:
Address relocation hardware on all S/370s except the original models 155 and 165
The new S/370-158 and -168
Four new operating systems: DOS/VS (DOS with virtual storage), OS/VS1 (OS/MFT with virtual storage), OS/VS2 (OS/MVT with virtual storage) Release 1, termed SVS (Single Virtual Storage), and Release 2, termed MVS (Multiple Virtual Storage) and planned to be available 20 months later (at the end of March 1974), and VM/370 – the re-implemented CP/CMS
Virtual memory had in fact been delivered on S/370 hardware before this announcement:
In June, 1971, on the S/370-145 (one of which had to be 'smuggled' into Cambridge Scientific Center to prevent anybody noticing the arrival of a S/370 at that hotbed of virtual memory development – since this would have signaled that the S/370 was about to receive address relocation technology). (Varian 1977:p29) The S/370-145 had relocation hardware (implemented in microcode) from its first shipments in June 1971. Although IBM famously chose to exclude virtual memory from the S/370 announcement, that decision was being reconsidered during the completion of the 145 engineering, due partly to virtual memory experience at CSC and elsewhere. The 145 microcode architecture simplified the addition of virtual memory, allowing the this capability to be present in early 145s without the extensive hardware modifications needed in other models. However, IBM did not document the 145's virtual memory capability, nor annotate the relevant bits in the control registers and PSW that were displayed on the operator control panel when selected using the roller switches. Existing S/370-145 customers were happy to learn that they did not have to purchase a hardware upgrade in order to run DOS/VS or OS/VS1 (or OS/VS2 Release 1 – which was possible, but not common because of the limited amount of main storage available on the S/370-145).
Shortly after the August 2nd, 1972 announcement, DAT box (address relocation hardware) upgrades for the S/370-155 and S/370-165 were quietly announced, but were available only for purchase by customers who already owned a Model 155 or 165. After installation, these models were known as the S/370-155-II and S/370-165-II. IBM wanted customers to upgrade their 155 and 165 systems to the widely-sold S/370-158 and -168. 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, majority of which leased their systems via a third-party leasing company. This led to the original S/370-155 and S/370-165 models being described as boat anchors. The upgrade, required to run OS/VS1 or OS/VS2, was not cost effective for most customers by the time IBM could actually deliver and install it, so many customers were stuck with these machines running MVT until their lease ended. It was not unusual for this to be another four, five or even six years for the more unfortunate ones, and turned out to be a significant factor[citation needed] in the slow adoption of OS/VS2 MVS, not only by customers in general, but for many internal IBM sites as well.
Later architectural changes primarily involved expansions in memory (central storage) – both physical memory and virtual address space – to support larger workloads and meet client demands for more storage. This was the inevitable trend as Moore's Law eroded the unit cost of memory. As with all IBM mainframe development, preserving backward compatibility was paramount.
In October 1981, the 3033 and 3081 processors added "extended real addressing," which allowed 26-bit addressing for physical storage (but still imposed a 24-bit limit for any individual address space). This capability appeared later on other systems, such as the 4381 and 3090.
The S/370-XA architecture, first available in early 1983 on the 3081 and 3083 processors, provided a number of major enhancements, including: expansion of the address space from 24-bits to 31-bits; facilitating movement of data between two address spaces; and a complete redesign of the I/O architecture. The cross-memory services capability which facilitated movement of data between address spaces was actually available just prior to S/370-XA architecture on the 3031, 3032 and 3033 processors.
The ESA/370 architecture (later named ESA/390) made further extensions, including the addition of sixteen 32-bit access registers, more addressing modes, and various facilities for working with multiple address spaces simultaneously.
Expanding the address space
As described above, the S/370 product line underwent a major architectural change: expansion of its address space from 24 to 31 bits.
The evolution of S/370 addressing was always complicated by the basic S/360 instruction set design, and its large installed code base, which relied on a 24-bit logical address. (In particular, a heavily-used machine instruction, "Load Address" (LA), explicitly cleared the top eight bits of the address being placed in a register. This created enormous migration problems for existing software.)
The strategy chosen was to implement expanded addressing in three stages:
First at the physical level (to enable more memory hardware per system)
Then at the operating system level (to let system software access multiple address spaces and utilize larger address spaces)
Finally at the application level (to let new applications access larger address spaces)
Since the core S/360 instruction set remained geared to a 24-bit universe, this third step would require a real break from the status quo; existing assembly language applications would of course not benefit, and new compilers would be needed before non-assembler applications could be migrated. Most shops thus continued to run their 24-bit applications in a higher-performance 31-bit world.
This evolutionary implementation (repeated in z/Architecture) had the characteristic of solving the most urgent problems first: Relief for real memory addressing being needed sooner that virtual memory addressing.
31 versus 32 bits
IBM's choice of 31-bit (versus 32-bit) addressing for S/370-XA involved various factors. The S/360-67 had included a full 32-bit addressing mode, but this feature was not carried forward to the S/370 series, which began with only 24-bit addressing. When IBM later expanded the S/370 address space in S/370-XA, several reasons are cited for the choice of 31 bits:
The desire to retain the high-order bit as a "control or escape bit." In particular, the standard subroutine calling convention marked the final parameter word by setting its high bit.
Interaction between 32-bit addresses and two instructions (BXH and BXLE) that treated their arguments as signed numbers (and which was said to be the reason TSS used 31-bit addressing on the S/360-67). (Varian 1977:p26, note 85)
Input from key initial S/360-67 sites, who had debated the alternatives during the initial system design period, and had recommended 31 bits (instead of the 32-bit design that was ultimately chosen at the time).
Series and models
The following table summarizes the major S/370 series and models. The middle column lists the principal architecture associated with each series. Many models supported more than one architecture; thus, 308x processors initially shipped as S/370 architecture, but later offered XA; and many processors, such as the 4381, had microcode that allowed customer selection between S/370 or XA (later, ESA) operation.
Note also the confusing term "System/370-compatible", which appeared in IBM source documents to describe certain products. Outside IBM, this term would more often describe systems from Amdahl Corporation, Hitachi Ltd., and others, that could run the same S/370 software. This choice of terminology by IBM may have been a deliberate attempt to ignore the existence of those plug compatible manufacturers (PCMs), because they competed aggressively against IBM hardware dominance.
|
No responses found. Be the first to respond and make money from revenue sharing program.
|