History notes . . .

False Compatibility Failed to Sway the Market

Conrad Weisert, April 1, 2011
ŠInformation Disciplines, Inc.

NOTE: This document may be circulated or quoted from freely, as long as the copyright credit is included.
"RCA had endeavoured to make its machines as nearly compatible with IBM's as possible . . . " —Britannica Book of the Year 1972, p. 197
"A line of IBM-compatible mainframes from RCA introduced in the late 1960s. The Spectra 70s were the first non-IBM machines to execute applications written for IBM's 360 mainframes . . ."

The Free dictionary

"In the late 1960s, RCA's computer division produced the Spectra 70, the first line of machines compatible with IBM's System/360."

PC Magazine Encyclopaedia.

No, not really. After IBM announced its System/360 line of third-generation computer systems in 1964, other computer manufacturers feared that the 360 would soon become a de facto standard in the industry. RCA, after vigorous internal debate, announced a bold decision: Their new line of computers would follow IBM's lead! A Spectra-70 system would be "compatible" with other mainstream machines (i.e. IBM's System/360).

Unfortunately for RCA they had based their decision on a naïve interpretation of what "compatibility" meant for computers.

If your programmers had developed applications in IBM 360 assembly language, they would indeed find the Spectra 70 familiar. The internal data formats, the registers, and the non-privileged1 instructions of the two machines were exactly the same. But in the mid-1960s very few programmers were coding serious applications in assembly language.

Background: Incompatibility was the norm

Every first- and second-generation computer model had its own unique architecture. The internal data formats, the instruction formats, the instruction repertoires, and the input-output interfaces of a large-scale Burroughs machine were entirely different from those of a large-scale GE machine and even different from Buroughs's own smaller machines. Customers that had become dependent on applications written in a particular vendor's assembly language had to confront huge reprogramming costs if they contemplated replacing their computer with another vendor's product.

That was appropriate as computer designers experimented with unproven ideas, but after being hit once or twice by huge conversion costs user organizaions began to agitate for an end to those burdens. Higher-level languages (mainly Fortran and Cobol) offered some hope. The U.S. Government, constrained by policy to obtain machines from multiple vendors, led the push for Cobol.

Incompatibilities

The things that were not compatible made it impossible for a System/360 installation to substitute a Spectra-70 configuration without a major conversion effort. The significant incompatibilities included:

  1. The "privileged" instructions, reserved for the operating system and low-level utility progams. That meant that the huge operating systems developed by IBM would not run on a Spectra-70 computer.

  2. The operating system interface ("supervisor calls") through which application programs invoked utility functions, including all input-output.

  3. The structure and format of object modules and executable ("load modules") programs.
So you couldn't run OS/360 on a Spectra-70 and you couldn't run an OS/360 application program under the Spectra-70 operating system. A familiar assembly language was little compensation. "From afar it's breathtaking; up close it's heartbreaking. "—audience comment after a 1966 RCA presentation.

Epilog: true compatibility

Later hardware manufacturers (Amdahl, Hitachi) brought out machines that were fully compatible with System/360 and its successors, mostly in the high-end, near supercomputer range. By that time IBM had unbundled its software from machine rental prices, so users could purchase and legally use IBM program products on those non-IBM machines. And IBM didn't sue them.

But by that time the sun had set on Spectra-70 and on RCA's role in the computer industry. RCA sold its computer business to Sperry Rand in 1971.


1—Non-privileged instructions were those that could be executed by application programs running in the so-called "problem state".   In theory they could not affect any concurrently running program or the operating system itself.

Last modified April 1, 2011

Return to IDI home page
Historical notes.