IBM Future Systems project

Future Systems project

Company type	Research and development project
Industry	Computer hardware and software
Predecessor	System/370
Founded	September 1971 (1971-09)
Defunct	February 1975 (1975-02)
Fate	Project terminated
Headquarters	Poughkeepsie , United States
Key people	Erich Bloch, Carl Conti, John McPherson, Bob O. Evans

The Future Systems project (FS) was an IBM research and development effort initiated in the early 1970s with the objective of developing a groundbreaking series of computer products. Its emphasis was on innovative software paradigms intended to streamline development by utilizing cutting-edge hardware. The initiative aimed to succeed the System/370 by the late 1970s.

The project revolved around two principal innovations. The first was a single-level store that enabled programs to access data stored on secondary storage devices such as disk drives as if it were located in main memory, thereby removing the need for explicit file management. The second innovation involved incorporating instructions that directly corresponded to high-level programming language commands, allowing programs to execute without prior compilation into machine code. For instance, code entered via a text editor could be executed immediately.

However, integrating these two features proved impractical. Despite early concerns raised by engineers, management proceeded with the plan. Officially launched in autumn 1971, the project encountered delays by 1974 and was ultimately terminated in February 1975. Although the concept of a single-level store was later realized in the System/38 (1978) and subsequent models, IBM never produced machines capable of directly executing high-level language instructions as envisioned.

System/370

Following the introduction of the System/360 in April 1964, IBM began analyzing future market developments to guide its next-generation systems. The emergence of practical integrated circuit (IC) technology promised more powerful computers at comparable prices by replacing numerous components with fewer ICs.

By the mid-1960s, the System/360 had achieved significant commercial success, creating strong demand for complete backward compatibility in its successor. Announced in 1970 as the System/370, it featured small-scale ICs, increased memory capacity, and modest enhancements while maintaining substantial programming compatibility with the 360.

Sales slowed during the recession of 1969–1970, causing System/370 orders between 1970 and 1971 to lag behind the rapid uptake experienced by the System/360 several years earlier. This marked IBM's first growth stagnation in decades. While some advocated for incremental upgrades to improve market appeal, others called for a comprehensive redesign to secure long-term competitiveness.

Replacing the System/370

Two months before unveiling the System/370, IBM reevaluated market trends shaping future system designs. In 1965, Gordon Moore predicted exponential growth in integrated circuit capacity—a principle now known as Moore's Law. IBM’s Jerrier A. Haddad observed that costs for logic and memory components were declining at rates too rapid to measure precisely.

An internal Corporate Technology Committee (CTC) projected a thirtyfold decrease in memory prices within five years, followed by another thirtyfold reduction over the next five years. To sustain sales growth, IBM needed to increase memory sales volume by thirty times within five years and by nine hundred times after ten years. Meanwhile, hard disk storage costs were anticipated to drop tenfold over a decade, requiring sales of forty times more disk space by 1980 to maintain a 15% annual growth rate.

Advancing from the System/360 through the System/370 and beyond implied developing future machines based on large-scale integration technologies that would reduce complexity and cost. Selling such advanced systems at existing price points was not viable because competitors could offer less expensive alternatives. Although more powerful computers could be priced similarly, customers were not fully utilizing current systems, so IBM needed to justify additional performance.

Moreover, while hardware expenses decreased, costs related to programming and operations—primarily labor—were steadily increasing. This trend threatened IBM’s revenue foundation as customers’ IT budgets allocated less for hardware. IBM aimed to lower total IT expenditures by addressing application development and operational costs in upcoming products, thereby capturing a greater portion of customer spending.

AFS

In 1969, Bob O. Evans, who led IBM’s System Development Division for mainframes, assigned Erich Bloch at the Poughkeepsie Laboratory the task of investigating ways to utilize more cost-effective components while maintaining profitability. Bloch designated Carl Conti to draft potential system designs, resulting in the formation of the Advanced Future Systems (AFS) team, which convened every two weeks.

A central idea emerging from AFS efforts was the adoption of virtual memory (VM) and the single-level store concept originally developed by the Multics project. This model treated all data as residing in main memory; when data was stored on secondary devices, it was transparently loaded into memory upon access. Programmers worked with data as variables without needing to handle file input/output operations, while the operating system managed synchronization with storage devices.

This notion aligned well with the then-nascent bubble memory technology, which anticipated future architectures combining core memory and disk storage into one extensive memory pool. Functioning effectively as single-level stores, these designs removed the distinction between file layers and application programming interfaces for data in memory versus on disk, thereby streamlining both programming and system architecture.

HLS

Evans also commissioned John McPherson at IBM’s headquarters in Armonk to lead a multidisciplinary team investigating how IBM could implement innovative designs across its divisions. Comprising twelve members from three different sectors, this group produced the "Higher Level System Report" (HLS), which was submitted on 25 February 1970. A significant conclusion was that programming expenses outweighed hardware costs; thus, systems that minimized development efforts could justify higher prices while reducing overall operational expenditures.

The System/360 family established a unified instruction set architecture (ISA) encompassing all instructions an assembly language programmer might require. Unlike prior systems optimized for specific applications, the 360 series provided instructions supporting a wide range of tasks. Individual models within the 360 lineup targeted particular functions by executing some instructions directly in hardware and others through microcode. This approach ensured software compatibility across different machines, allowing customers to upgrade hardware without needing to alter their applications—a critical competitive advantage.

Despite its breadth, the 360 ISA consisted of low-level CPU commands such as "add two numbers." High-level programming languages and compilers translated user commands into these machine-level instructions.

The HLS report recommended raising instruction abstraction levels to represent complex operations directly—for instance, an instruction like "open file" would be executed internally by microcode or hardware without further translation. This idea complemented the single-level store model: each data item was associated with a descriptor specifying its type, location, precision, and size. Descriptors could point to arrays or records, enabling machine code to manipulate intricate objects atomically.

By natively supporting higher-level objects, programs could be shortened and simplified. Traditionally, adding two arrays stored in files involved opening files, reading elements, performing additions, and writing results back. Under HLS principles, simply opening files and issuing an add instruction sufficed—the operating system mapped files into memory with descriptors identifying arrays so that the add instruction operated on entire arrays simultaneously. This approach condensed extensive code into a few lines and allowed command shells themselves to be programmable using these high-level instructions.

The report concluded:

Compatibility Issues

Up until the late 1960s, IBM generated the majority of its revenue from hardware sales, typically packaging software and services without distinct pricing. However, competitors began producing compatible peripherals such as tape units and disk drives at more competitive prices, which diminished IBM’s ability to recover costs associated with software and services. In response, IBM refused to service machines equipped with third-party additions, a practice that led to antitrust scrutiny. Consequently, in 1969, IBM discontinued bundling and started marketing software as a separate product.

Gene Amdahl recognized an opportunity in the market for compatible hardware sold independently of software; customers could purchase equipment from Amdahl while obtaining software directly from IBM. Should IBM decline to sell software separately, it would risk violating legal requirements. In 1970, Amdahl departed from IBM to establish a company producing System/370-compatible machines that offered greater speed and cost efficiency compared to IBM’s premium models.

Although initially unconcerned due to the continued profitability of software and support services, IBM initiated Project Counterpoint in early 1971 to analyze the competitive mainframe landscape. This internal study confirmed the market potential for compatible systems and acknowledged that bundling software with hardware would become less sustainable. As a result, IBM sought strategies to encourage customers to purchase all components exclusively from IBM without breaching antitrust regulations.

The recommendations from the HLS report implied that rivals would have to replicate microcode responsible for implementing extensive instruction sets—a move potentially infringing on copyrights. This development rekindled internal interest in the AFS/HLS concepts.

Future Systems

Between May and June 1971, an international task force led by IBM Vice President John Opel assembled in Armonk to explore the feasibility of a new computing line designed to render obsolete not only competitors’ products but also IBM’s own existing systems. The group concluded that while the project was feasible, achieving substantial reductions in application development and maintenance expenses was essential for successful market adoption.

The objectives of the Future Systems (FS) initiative included:

• Rendering all current computing equipment obsolete by utilizing state-of-the-art technologies,
• Dramatically lowering costs associated with application development and system operations,
• Facilitating the re-integration of IBM’s hardware, software, and services on a robust technical platform.

IBM anticipated that taking advantage of increasingly cost-effective hardware resources would streamline software creation and reduce expenses for both itself and its clientele.

Data Access

A fundamental design element of FS was the implementation of a single-level store, which extended virtual memory (VM) concepts to encompass persistent data storage. Traditionally, programs allocate memory for data that is lost upon powering down, necessitating additional programming efforts to save and reload information from permanent storage devices such as hard drives. During the 1960s, database engines were developed to manage this complexity.

Virtual memory addressed physical memory limitations by defining an extensive maximum address space and swapping data between main memory and disk storage as needed. The single-level store concept broadens this approach by managing all memory—both internal and external—under VM control. This design removes the need for explicit save/load operations; data and executing programs persist seamlessly through system restarts.

Although investigated in Multics, single-level stores suffered from slow performance due to hardware constraints, as core memory was supported by slower disks or drums. The emergence of faster non-volatile memory technologies such as bubble memory, offering speeds comparable to core memory with greater density, made single-level stores more practical.

Future Systems intended to place the single-level store at the heart of its operating system architecture. Rather than relying on separate database engines, system API calls would access memory directly by leveraging hardware or microcode tailored specifically for IBM platforms—consistent with IBM's approach of closely integrating hardware and software components.

Processor

The FS architecture utilized highly sophisticated instructions implemented through microcode. For instance, the CreateEncapsulatedModule command operated as a fully integrated linkage editor. Additional instructions supported internal data structures and operations tailored for programming languages such as FORTRAN, COBOL, and PL/I. Essentially, FS was engineered as an advanced complex instruction set computer (CISC).

This design merged functionalities typically distributed among hardware components, operating system software, and data base software into a single unified system. Basic operations were executed across several layers, including hardware circuitry, microcode, and traditional software. The architecture incorporated multiple microcode layers—often referred to as picocode or millicode—within its structure. The concept of "machine" ranged from hardware-embedded functions to the complete set of features accessible to end users.

A distinctive element was the "universal controller," a dedicated unit managing input-output functions independently from the main processor. This controller employed a streamlined instruction set focused solely on I/O activities, representing an early instance of a reduced instruction set computer (RISC) design.

Concurrently, John Cocke, IBM’s principal architect, initiated pioneering work on RISC architecture. His efforts produced the IBM 801 RISC design, which later evolved into IBM's POWER, PowerPC, and Power families. These RISC-based architectures demonstrated greater cost efficiency and achieved faster clock speeds compared to traditional CISC models.

Project start

The FS initiative formally commenced in September 1971 following recommendations from a dedicated task force earlier that year. Over time, multiple IBM research programs either merged with or became affiliated with the FS project.

Project management

Throughout its lifespan, the FS project maintained rigorous security measures. It was organized into numerous subprojects overseen by distinct teams, with documentation divided accordingly and access strictly limited based on necessity. All documents were monitored and subject to retrieval at any moment.

As highlighted in Sowa’s memorandum, this extensive compartmentalization strategy was intended to prevent any individual from fully understanding the entire system—a goal that was successfully met. As a result, most participants had a restricted perspective confined to their particular responsibilities; some teams contributed to FS without comprehensive knowledge of the overall project scope. This segmentation explains why descriptions of FS often reflected only isolated aspects tied to specific areas of expertise.

Planned product lines

The FS architecture was planned for implementation across three primary tiers: a high-end model developed in Poughkeepsie, NY, IBM’s center for its largest and fastest systems; a mid-level model based in Endicott, NY; and a lower-end model produced in Böblingen, Germany. Additionally, the smallest variant was designed in Hursley, UK. By adjusting processor quantities within these four tiers, a seamless performance spectrum could be achieved.

In early 1973, overall project oversight and teams responsible for shared system layers were centralized at the Mohansic ASDD facility situated between IBM’s Armonk/White Plains headquarters and Poughkeepsie.

Project termination

The Future Systems initiative was discontinued in 1975, primarily due to a range of persistent difficulties involving circuit architecture, production processes, marketing strategies, and system upkeep. Although some individual obstacles might have been tackled independently, addressing all of them concurrently within the project timelines proved unattainable.

Major challenges encompassed subpar performance on the largest-scale implementation and internal disputes at IBM regarding RISC versus CISC architectural approaches. The instruction set was deemed overly intricate, with even IBM engineers describing it as "unintelligible." Furthermore, the concept of a unified single-level store presented backup constraints that anticipated the partitioning method later employed by the IBM AS/400 for System/38 storage. Performance simulations indicated that executing native Future Systems instructions on advanced hardware was slower than running a System/370 emulator on identical machines.

Ultimately, IBM decided to halt the Future Systems project upon recognizing limited market acceptance, largely due to the absence of a practical migration path for applications transitioning from the System/360 architecture. The project prioritized groundbreaking design innovation, deferring migration simplification to software solutions; however, migrating extensive COBOL and assembly language codebases frequently resulted in expenses exceeding those of adopting new systems outright.

Outcomes

Despite the cancellation of Future Systems, development persisted on a streamlined architecture designed for the smallest of the three planned machines at Rochester, which eventually led to the creation of the IBM System/38. This platform was lauded for its programming simplicity but was hindered by modest performance capabilities. Its successor, the AS/400, inherited this foundational design while incorporating substantial performance improvements. Both systems operated by translating high-level compiler commands into a lower-level machine instruction set—initially a CISC set bearing resemblance to the System/360 architecture. Subsequent iterations transitioned to an expanded PowerPC instruction set inspired by John Cocke’s IBM 801 RISC developments. By 2008, dedicated hardware gave way to the IBM Power Systems platform running the IBM i operating system.

Beyond System/38 and AS/400, several IBM products incorporated technologies derived from Future Systems:

• The IBM 3081 mainframe—a premium design from Poughkeepsie—utilized System/370 emulator microcode alongside repurposed FS microcode
• The 3800 laser printer, whose early models influenced the IBM 3279 terminal and GDDM
• The IBM 3850 automated magnetic tape library
• The IBM 8100 midrange computer, built around the Universal Controller CPU initially designed for FS input/output processing
• Networking advancements related to VTAM and NCP

External links

• Analysis of a publication examining IBM’s setbacks, with emphasis on the Future Systems project’s impact
• A 1974 internal memorandum by John F. Sowa discussing technical and organizational hurdles faced during FS development
• Summary overview of IBM Future Systems