Editing IBM Future Systems project (section)

== History ==
===370===
The [[System/360]] was announced in April 1964. Only six months later, IBM began a study project on what trends were taking place in the market and how these should be used in a series of machines that would replace the 360 in the future. One significant change was the introduction of useful [[integrated circuit]]s (ICs), which would allow the many individual components of the 360 to be replaced with a smaller number of ICs. This would allow a more powerful machine to be built for the same price as existing models.{{sfn|Case|2006|p=47}}

By the mid-1960s, the 360 had become a massive best-seller. This influenced the design of the new machines, as it led to demands that the machines have complete backward compatibility with the 360 series. When the machines were announced in 1970, now known as the [[System/370]], they were essentially 360s using small-scale ICs for logic, much larger amounts of internal memory and other relatively minor changes.{{sfn|Case|2006|p=54}} A few new instructions were added and others cleaned up, but the system was largely identical from the programmer's point of view.{{sfn|Case|2006|p=57}}

The [[recession of 1969–1970]] led to slowing sales in the 1970-71 time period and much smaller orders for the 370 compared to the rapid uptake of the 360 five years earlier.{{sfn|Pugh|1991|p=541}} For the first time in decades, IBM's growth stalled. While some in the company began efforts to introduce useful improvements to the 370 as soon as possible to make them more attractive, others felt nothing short of a complete reimagining of the system would work in the long term.{{sfn|Case|2006|p=57}}

===Replacing the 370===
Two months before the announcement of the 370s, the company once again started considering changes in the market and how that would influence future designs.{{sfn|Case|2006|p=57}} In 1965, [[Gordon Moore]] predicted that [[integrated circuit]]s would see exponential growth in the number of circuits they supported, today known as [[Moore's Law]]. IBM's [[Jerrier A. Haddad]] wrote a memo on the topic, suggesting that the cost of logic and memory was going to zero faster than it could be measured.{{sfn|Case|2006|p=57}}

An internal Corporate Technology Committee (CTC) study concluded a 30-fold reduction in the price of memory would take place in the next five years, and another 30 in the five after that. If IBM was going to maintain its sales figures, it was going to have to sell 30 times as much memory in five years, and 900 times as much five years later. Similarly, hard disk cost was expected to fall ten times in the next ten years. To maintain their traditional 15% year-over-year growth, by 1980 they would have to be selling 40 times as much disk space and 3600 times as much memory.{{sfn|Pugh|1991|p=541}}

In terms of the computer itself, if one followed the progression from the 360 to the 370 and onto some hypothetical System/380, the new machines would be based on large-scale integration and would be dramatically reduced in complexity and cost. There was no way they could sell such a machine at their current pricing, if they tried, another company would introduce far less expensive systems.{{sfn|Case|2006|p=57}} They could instead produce much more powerful machines at the same price points, but their customers were already underutilizing their existing systems. To provide a reasonable argument to buy a new high-end machine, IBM had to come up with reasons for their customers to need this extra power.{{sfn|Case|2006|p=58}}<ref name=sowa1>{{cite web |title=Advanced Future Systems |first=John |last=Sowa |url=http://www.jfsowa.com/computer/afs/index.htm |date=2016}}</ref>

Another strategic issue was that while the cost of computing was steadily going down, the costs of programming and operations, being made of personnel costs, were steadily going up. Therefore, the part of the customer's IT budget available for hardware vendors would be significantly reduced in the coming years, and with it the base for IBM revenue. It was imperative that IBM, by addressing the cost of application development and operations in its future products, would at the same time reduce the total cost of IT to the customers and capture a larger portion of that cost.<ref name=sowa1 />

===AFS===
In 1969, [[Bob O. Evans]], president of the  IBM System Development Division which developed their largest [[mainframe]]s, asked [[Erich Bloch]] of the [[IBM Poughkeepsie Lab]] to consider how the company might use these much cheaper components to build machines that would still retain the company's profits. Bloch, in turn, asked [[Carl Conti]] to outline such systems. Having seen the term "future systems" being used, Evans referred to the group as Advanced Future Systems. The group met roughly biweekly.

Among the many developments initially studied under AFS, one concept stood out. At the time, the first systems with [[virtual memory]] (VM) were emerging, and the seminal [[Multics]] project had expanded on this concept as the basis for a [[single-level store]]. In this concept, all data in the system is treated as if it is in [[main memory]], and if the data is physically located on [[secondary storage]], the VM system automatically loads it into memory when a program calls for it. Instead of writing code to read and write data in files, the programmer simply told the operating system they would be using certain data, which then appeared as objects in the program's memory and could be manipulated like any other [[variable (computer science)|variable]]. The VM system would ensure that the data was synchronized with storage when needed.<ref name=hansen>{{cite magazine |first=Bill |last=Hansen |date=11 March 2019 |title=Fifty Years of Operating IBM Systems |magazine=The Four Hundred |volume=29 |issue=15 |url=https://www.itjungle.com/2019/03/11/fifty-years-of-operating-ibm-systems/}}</ref>

This was seen as a particularly useful concept at the time, as the emergence of [[bubble memory]] suggested that future systems would not have separate [[core memory]] and [[disk drive]]s, instead everything would be stored in a large amount of bubble memory.<ref name=hansen/> Physically, systems would be single-level stores, so the idea of having another layer for "files" which represented separate storage made no sense, and having pointers into a single large memory would not only mean one could simply refer to any data as it if were local, but also eliminate the need for separate [[application programming interface]]s (APIs) for the same data depending on whether it was loaded or not.<ref name=hansen/>

===HLS===
Evans also asked [[John McPherson (computer engineer)|John McPherson]] at IBM's [[Armonk, New York|Armonk]] headquarters to chair another group to consider how IBM would offer these new designs across their many divisions. A group of twelve participants spread across three divisions produced the "Higher Level System Report", or HLS, which was delivered on 25 February 1970. A key component of HLS was the idea that programming was more expensive than hardware. If a system could greatly reduce the cost of development, then that system could be sold for more money, as the overall cost of operation would still be lower than the competition.<ref name=hlsrep>{{cite tech report |url=http://www.jfsowa.com/computer/afs/HLS_1970.pdf |title=Higher Level System (HLS) |date=25 February 1970 |first=John |last=McPherson}}</ref>

The basic concept of the System/360 series was that a single [[instruction set architecture]] (ISA) would be defined that offered every possible instruction the [[assembly language]] programmer might desire. Whereas previous systems might be dedicated to scientific programming or currency calculations and had instructions for that sort of data, the 360 offered instructions for both of these and practically every other task. Individual machines were then designed that targeted particular workloads and ran those instructions directly in hardware and implemented the others in [[microcode]]. This meant any machine in the 360 family could run programs from any other, just faster or slower depending on the task. This proved enormously successful, as a customer could buy a low-end machine and always upgrade to a faster one in the future, knowing all their applications would continue to run.

Although the 360's instruction set was large, those instructions were still low-level, representing single operations that the [[central processing unit]] (CPU) would perform, like "add two numbers" or "compare this number to zero". [[Programming language]]s and their links to the operating system allowed users to type in programs using high-level concepts like "open file" or "add these arrays". The [[compiler]]s would convert these higher-level abstractions into a series of [[machine code]] instructions.

For HLS, the instructions would instead represent those higher-level tasks directly. That is, there would be instructions in the machine code for "open file". If a program called this instruction, there was no need to convert this into lower-level code, the machine would do this internally in microcode or even a direct hardware implementation.<ref name=hlsrep/> This worked hand-in-hand with the single-level store; to implement HLS, every bit of data in the system was paired with a ''descriptor'', a record that contained the type of the data, its location in memory, and its precision and size. As descriptors could point to arrays and record structures as well, this allowed the machine language to process these as atomic objects.<ref name=hlsrep/>

By representing these much higher-level objects directly in the system, user programs would be much smaller and simpler. For instance, to add two arrays of numbers held in files in traditional languages, one would generally open the two files, read one item from each, add them, and then store the value to a third file. In the HLS approach, one would simply open the files and call add. The underlying operating system would map these into memory, create descriptors showing them both to be arrays and then the add instruction would see they were arrays and add all the values together. Assigning that value into a newly created array would have the effect of writing it back to storage. A program that might take a page or so of code was now reduced to a few lines. Moreover, as this was the natural language of the machine, the [[command shell]] was itself programmable in the same way, there would be no need to "write a program" for a simple task like this, it could be entered as a command.<ref name=hlsrep/>

The report concluded:

{{quote|The user and IBM should both gain substantially from the easier coding and debugging of concise programs. We expect to sharply reduce the cost of programming and the size of complex programs, as both program quality and programmer productivity are enhanced.<ref name=hlsrep/>}}

===Compatible concerns===
Until the end of the 1960s, IBM had been making most of its profit on hardware, bundling support software and services along with its systems to make them more attractive. Only hardware carried a price tag, but those prices included an allocation for software and services.<ref name=hansen />

Other manufacturers had started to market compatible hardware, mainly peripherals such as tape and [[disk drives]], at a price significantly lower than IBM, thus shrinking the possible base for recovering the cost of software and services. IBM responded by refusing to service machines with these third-party add-ons, which led almost immediately to sweeping [[anti-trust]] investigations and many subsequent legal remedies. In 1969, the company was forced to end its bundling arrangements and announced they would sell software products separately.{{sfn|Aspray|2000|pp=27, 28}}

[[Gene Amdahl]] saw an opportunity to sell compatible machines without software; the customer could purchase a machine from Amdahl and the [[operating system]] and other software from IBM. If IBM refused to sell it to them, they would be breaching their legal obligations. In early 1970, Amdahl quit IBM and announced his intention to introduce System/370 compatible machines that would be faster than IBM's high-end offerings but cost less to purchase and operate.{{sfn|Aspray|2000|p=32}}

At first, IBM was unconcerned. They made most of their money on software and support, and that money would still be going to them. But to be sure, in early 1971 an internal IBM task force, Project Counterpoint, was formed to study the concept. They concluded that the compatible mainframe business was indeed viable and that the basis for charging for software and services as part of the hardware price would quickly vanish. These events created a desire within the company to find some solution that would once again force the customers to purchase everything from IBM but in a way that would not violate antitrust laws.<ref name=hansen/>

If IBM followed the suggestions of the HLS report, this would mean that other vendors would have to copy the [[microcode]] implementing the huge number of instructions. As this was software, if they did, those companies would be subject to copyright violations.<ref name=hansen/> At this point, the AFS/HLS concepts gained new currency within the company.

===Future Systems===
In May–June 1971, an international task force convened in [[Armonk]] under [[John Opel]], then a vice-president of IBM. Its assignment was to investigate the feasibility of a new line of computers which would take advantage of IBM's technological advantages in order to render obsolete all previous computers - compatible offerings but also IBM's own products. The task force concluded that the project was worth pursuing, but that the key to acceptance in the marketplace was an order-of-magnitude reduction in the costs of developing, operating and maintaining application software.

The major objectives of the FS project were consequently stated as follows:
*make obsolete all existing computing equipment, including IBM's, by fully exploiting the newest technologies,
*diminish greatly the costs and efforts involved in application development and operations,
*provide a technically sound basis for re-bundling as much as possible of IBM's offerings (hardware, software and services)

It was hoped that a new architecture making heavier use of hardware resources, the cost of which was going down, could significantly simplify software development and reduce costs for both IBM and customers.