Vigilance and Vacuum Tubes: The SAGE System 1956-63
The following is a verbatim transcript of a public lecture given on May 19, 1998.
This transcript is © Copyright 1998 by The Computer Museum History Center and is for
private individual use only.
It may not be published, in any form, in whole or in part, without prior written permission of
The Computer Museum History Center.
Tel: +1 650 604 2579
Vigilance and Vacuum Tubes: The SAGE System 1956-63”
Les Earnest, Jim Wong, Paul Edwards
5:30 - 7:00 PM
Tuesday, May 19
The Computer Museum History Center
Building 126
Moffett Field
Mountain View, CA 94035
PETER NURKSE:
Hello, I’m Peter Nurkse from Sun Microsystems, and some of you I’ve seen coming to these
talks for five years! You know, it’s been five years now that we’ve been holding these Bay
Area Computer History Perspectives talks, and with the Computer Museum now since the
arrival of the Computer Museum from Boston. I remember right now—what I’m thinking of is
our last talk at the end of March, which was so cold, it was freezing! That was, before the
end of March would be a reasonable time to have a talk here in an unheated area, but this
year hasn’t been an unusual year. And then, thinking farther back, a talk that comes to mind
is ILLIAC IV, we had a talk on ILLIAC IV here at NASA, and I remember in particular how
we were all amazed that ILLIAC IV consumed 250,000 watts, just ILLIAC IV itself, and
another 250,000 watts to try and cool it.
So now, here we have SAGE which consumed one million watts, that puts ILLIAC IV in its
place. One million watts, that was just for one computer, and there were two computers in
each SAGE center, and there were 22 SAGE centers around the country. So you can figure
how many megawatts were going into SAGE, just out of the domestic electrical production.
And this is really special, because we have the speakers talking right in front of pieces of
SAGE, which is a huge computer—there’s only small pieces of it here. And when we project
the video, the screen isn’t quite big enough so parts of the video will be projected onto
SAGE itself! [Laughter] SAGE is really here this evening!
So we’ll start with the video, which is the classic Air Force film of the era, and then Paul
Edwards will speak. As I checked before we began, Paul was age 1 in 1958, when SAGE was
first implemented! But, Paul has observations on SAGE. And this is example history, each
generation comes back and looks at history, and in computer history we’re already at the
stage where we have a second or a third generation coming back and looking at events and
what happened.
And then we have two veterans of the era: Les Earnest, who’ll be talking on hardware, and
Jim Wong, who’ll be talking on software. So you’ll really have the overall picture of SAGE.
I’ll mention, our next program is scheduled at this time for June 16 at Xerox Park on the
Star computer, and it’ll feature a working Xerox Star. And we are able to present a working
Xerox Star because Dave Curbow of Sun Microsystems has 12 Stars in his home, which he
cannibalizes in order to get one running from time to time. He thinks he can get one running,
one last time, for this last talk. That’s June 16, Xerox Park.
OK, so perhaps we can start now with the video.
VIDEO OF U.S. AIR FORCE FILM, “In Your Defense” (Video not available)
One of the most dangerous threats to our nation’s security is the possibility of attack by
high-speed enemy bombers armed with nuclear weapons. These bombers can strike at
supersonic speeds from many directions and altitudes to confuse our defense and delay the
dispatch of interceptor weapons. In a mass raid, high-speed bombers could be in on us
before we could determine their tracks. And then it would be too late to act. We cannot
afford to take that chance.
It is to meet this threat that the Air Force has been developing SAGE, the Semi-Automatic
Ground Environment System, a network of geographical defense sectors covering the
continental United States and extending into Canada. Each sector has as its focal point a
computer installation known as a Direction Center. A group of sectors comprise a NORAD
division, where the key point is a computer installation called a Combat Center. Combat
Centers are headquarters for higher echelons of command, integrating the individual sectors
into a centralized defense system.
Let’s suppose an enemy launched a surprise attack with high-speed aircraft, intent on
destroying our great cities. The long-range radars, which constantly scan the skies, detect
all planes in flight. The information is flashed electronically to the Direction Center, where
the computer instantaneously makes the necessary calculations and displays its findings as
tracks on the scopes of the consoles. In the Air Surveillance Section, tracking operators
monitor all traffic in the sector, and quickly relay unidentified tracks to operators in the
Identification Section, who determine that the tracks are hostile.
An alarm sounds in the Weapons Direction section. The Senior Director, and Senior Weapons
Director, size up the threat, using all the up-to-the-minute information displayed before
them on the scope. On the basis of this information, constantly supplied by the computer,
the track is assigned to a Weapons Director, who decides that interceptor aircraft should
be sent against the enemy. Immediately, the Weapons Director assigns the control of the
intercept to an Intercept Director, whose situation display shows him that fighter craft
have been scrambled. The situation display also indicates that the interceptors are assigned
to track A-137. “I” indicates interceptor aircraft, “G” that tracking is good, “1” the number
of the controlling Weapons Director, “2” the number of the Intercept Director. A vector
symbol indicates the heading of the fighters as they fly toward the point at which
interception will take place. RL-15 is the intercept flight code number.
Thus the Intercept Director has the information he needs to direct his portion of the air
battle. And the battle begins. At 28,000 feet, the bombers speed toward their targets. Jet
interceptors roar to the attack, guided by electronic impulses received directly from the
computer, supervised by the Intercept Director, miles away. Now comes the test. Were the
calculations correct? Were our judgments right? With weapons rushing toward each other
faster than the speed of sound, the slightest error can mean failure, and bombers free to
strike with nuclear bombs.
The console display shows the intercept weapons approaching. And the battle is joined. The
fighters lock on target, and rockets are fired.
The battle is over, the enemy destroyed. But one important task yet remains for the
computer: to guide the interceptors safely back to their bases.
The SAGE System provides us, on the North American continent,. the finest possible air
defense against attack by manned bombers, the number one threat of today, and quite a few
tomorrows.
END OF AIR FORCE VIDEO
PAUL EDWARDS:
I’m Paul Edwards. I don’t know if anybody can compete with what we just saw [laughter], so
please forgive me if I’m not quite as brilliant as that.
As Peter pointed out earlier, I was far too young to have worked on this project, or even to
have seen much of it in action. So as not to embarrass myself, I’m going to speak as quickly
as I can and leave the details of the participant action to those who were there: Les and
James. Part of what I want to do is, Les and James are going to talk about the hardware and
the software of SAGE, and I will leave out many of the technical details and talk about the
political context in which SAGE came into being. Which was, of course, the early part of the
cold war.
SAGE actually began in 1944, before the war was over, as the Airplane Stability and Control
Analyzer, which was an analog computer designed to serve as a controller for a flight
simulator. Flight simulators in this period were basically little boxes that you could get into,
whose attitude would change—you’d work them with a stick, and it would simulate an airplane
in that sense. The idea of the Airplane Stability and Control Analyzer was to build a general
purpose flight simulator that could be programmed with the characteristics of any airplane,
for the purposes of training pilots or perhaps for designing the aircraft itself, so you could
see how it would respond to the controls.
The project was handed, by the Navy’s Special Devices Center, to the MIT Servomechanisms
Laboratory. Jay Forrester, who was then an advanced graduate student—he had come to
MIT in 1940 and joined the Servomechanisms Lab— took on this project as the leader. He
spent about a year trying to make this analog computer work for this purpose. It’s important
to realize, I think, that in this period it was not obvious that there was a better way to do it
than that. Digital computers were, of course, under development, but nobody really knew
that they could be made to work, to work reliably, to do the kinds of things that Forrester
wanted them to do. And Forrester’s main problem with the analog techniques was not that
they were inaccurate, though they were, of course, because, as you all know, analog
computers have inherently limited accuracy. His main problem was that they were slow,
because they were electromechanical, in those days; they were ball-and-disk or motor-drive
analog machines. And for a flight simulator you need a real-time controller, because what you
are testing is the response of the aircraft to the controls. This meant that the computer
had to work with what was then extreme speed.
He gradually came to believe that it would be better to go with a digital technique, and
around 1946 he switched to that technique after hearing about the ENIAC and other
projects. Then he faced a different set of problems. One of the worst of these was the
unreliability of vacuum tubes. They were expensive, and they burned out a lot, so as the
computer ran, it would constantly be burning out tubes; it meant that they had to be found
and replaced, and caused lots of downtime.
Forrester was able to solve that problem eventually by redesigning the tubes; he actually
made some major contributions to that problem.
The computer for the flight simulator had some unique features, the main ones being that it
was designed for real-time operation and for control computing. Virtually all other digital
computer projects at that time were calculators. They were going to be used for science:
for off-line calculation of complicated mathematical problems. Forrester’s goal was much
more linked with the machine he was actually trying to control. So, to achieve speed, control,
and reliability, meant that this project cost a lot of money. The final total spent on the
Whirlwind computer, which was a digital version of the ASCA [Airplane Stability and Control
Analyzer], was about five million dollars, in 1950’s dollars; that today would be about 20-40-
who knows- some much higher number. Other computer projects of this period were
typically $100,000 to $500,000. So, Whirlwind was 10 times as expensive as even the most
expensive of most of the other projects around.
Here’s Forrester. One of the inventions that he made for the SAGE project was core
memory. Actually, co-invented at the same time—around the same time—by somebody from
RCA, but this is him, with a core memory plane, and I’m sure the others will talk later about
the cores that are in these boxes you see up here.
Remember that up through 1948, the idea of Whirlwind was that it was going to be a
controller for a flight simulator. The Office of Naval Research, which was paying for this
project, was rapidly losing interest, because they were spending millions of dollars a year for
what they were now starting to see was really only another general-purpose digital computer
project. At that time there were already 13 other digital computer projects, also very
expensive, being funded by various agencies, and the question was, “Why shall we pay for this
one?”
For the 1949 fiscal year, MIT requested 1.5 million dollars for the Whirlwind project. That
would have amounted to something like 80% of the ONR mathematics program budget, and
about 20% of the total amount that the ONR was spending on all contract research put
together. The actual budget was $1.2 million for that year, so there was a really huge
investment in this project. But it was made very clear to Forrester that if he did not
produce results, in the form of a working simulator controller, very soon, he was going to
lose his sponsor.
So in ‘48-‘49 Forrester began to cast about for new sponsors, and, therefore, for new
justifications for the project, since—flight simulator—so what? He was in a good position to
do this because during the immediate period after the war he had already been looking at all
kinds of applications for his machine; not just military ones, but also things like insurance
calculations. He had gone into quite some depth in thinking about how digital computers could
be used for fire control; that’s the problem of controlling guns. He had thought about a
digital computer as the centerpiece of a combat information center, the sort of telecomm
center on a ship, and he had written a couple of long reports about digital computers as
controllers for defense systems in naval and antisubmarine warfare.
By 1948 he had done so much of this thinking that the Whirlwind group was able to develop a
plan—a 15-year plan—for digital computers in military operations. They projected that it
would cost two billion dollars to carry out this program, and that digital computers would be
applied to air traffic control, missile guidance, logistics, fire control, and, especially
important here, real-time computerized command and control. This was an enormous vision,
much bigger than what most people were thinking about for digital computers at this period.
Well, Forrester was lucky. He had this set of justifications more or less pre-prepared; he
still needed a sponsor; and right around the time when Whirlwind was about to be killed—the
proposal was to cut its budget to about 10% of what it had been for the 1950 fiscal year—
the Soviet Union set off its first atomic bomb, in 1949. Now, here’s where the context gets
very interesting. The Air Force, before and during World War II, thought about air defense
as not what we think of today, that is, defending against an incoming attack, but as
destroying the sources of enemy fire. That’s defending yourself against an air attack. Well,
that could mean destroying them before they leave the ground. In fact, the initial use of
this term was in the context of using airplanes to attack ships at sea, because they would be
shelling the land, and you would send an airplane out to destroy them.
Up to 1949 there were no Soviet nuclear weapons. There had been a campaign for a better
radar-based continental air defense in 1948, but it had failed, and the only air defense
program that had been approved was a very, very minimal lash-up system, it was called, that
was going to have something like 85 radar stations to cover the entire United States. Then
the Soviet atomic bomb was exploded, and immediately this posture of very little air
defense became a serious public relations problem for the Air Force. Civilians began to
demand an active air defense, particularly those who lived in Washington State around the
Hanford Nuclear Reservation, Boeing, and so on. They were not that far from the Soviet
Union and they could see the problem.
At this point what began to happen was that immense amounts of money began to flow into
the Air Force and the rest of the services to meet this problem. And they tried all kinds of
things. They speeded up construction on the lash-up radar system. One of my favorite little
stories from this period is something called the Ground Observer Corps. This was a
volunteer program, begun in about this period, which consisted of setting up observation
platforms, mostly along the northern border of the U.S. and up into Canada. And the Air
Force had a radio ad campaign that asked people to volunteer to serve their country, to
defend against incoming bombers. So it sent these people up onto the platforms where they
would watch the sky with binoculars.
And they saw lots of things! [Laughter] They saw airplanes—many of them were civilian; they
saw birds; they saw all kinds of things, and most of them they thought were Soviet bombers.
I mean, this was a scary period. They would then telephone the nearest air base, which
would then have to figure out if this information was worth anything. And pretty much none
of it was worth anything. So, it very rapidly became obvious that despite the huge size of
this program—there were 8,000 observation posts, and at the peak of the program 305,000
volunteers staffing these things 24 hours a day— the information was pretty much useless.
So, commanders just ignored it. For one thing, by the time it had been verified, the
bombers would already be there. So, what was the point?
The reason I’m telling you this story is that the purpose of this program was not really air
defense. It was public relations. It was saying to the public, “We are doing something about
this problem—we see it.” At the same time, the Air Force started looking everywhere for
ideas from scientists and engineers, and [referring to the slide presentation] now we’ re
restarting, and I’m not sure what’s going on.
There was another factor here, and that was that the strategic doctrine of the 15 years or
so following World War II was basically this: the best defense is a good offense. And this
goes back again to that prewar period when the idea of air defense was to attack the source
of enemy fire at the earliest possible point. The U.S. has a huge perimeter. Protecting the
whole thing seemed like an impossible task. It would be easier, and better, to get there
first. And that, in fact, was the strategy. It was known as “prompt use.” This is basically a
doctrine of preemptive strike. The idea was, we would be watching with every means at our
disposal for movements of aircraft that looked like they might be mobilizing for a strike,
and if it got far enough, we would simply bomb them before they got off the ground. For
this reason, the Air Force did not actually expect to need a continental air defense. There
was no point in it.
This strategy was adopted for a number of reasons. One of them was that there were very
few nuclear weapons in this period; it took more than a decade for significant numbers of
them to be assembled, so that using them at all meant that you had to use them before they
might be destroyed here.
There’s another reason for this, a strategic reason, which is the problem of air defense. The
perimeter is huge, the issue of even finding the enemy bombers at all, when they might be
flying under your radar, or whatever, was hard. How do you maintain coordination of a
defense effort on that scale?
There was the issue of whether you could shoot them down. The best kill ratios historically
recorded in air warfare were during the Battle of Britain, when about 10% of attacking
planes were shot down. That worked in the Battle of Britain—it was won—but it wouldn’t
work in nuclear war, because even half a dozen airplanes getting through is still a
catastrophe.
Finally, there’s the problem, as we all probably remember from the cold war, of hair
triggers. That is, preventing false alerts and the launch of an attack in a situation which is
not actually warranted.
So, a guy named George Valley, another MIT professor, was assigned basically to this task
by the Air Force, and he heard about the Whirlwind. He decided to adopt it for radar
calculations in a large-scale, sort of high-tech, air defense system. He met Forrester, he saw
these various reports that Forrester had already prepared for other military applications of
computers, and he was impressed. He ended up rescuing the Whirlwind and using it as the
basis for SAGE.
The plan for SAGE was developed at MIT during some summer studies in 1951-52. It was
called something else then. It was actually called the Linco ln Transition System for a while.
I think the name SAGE came in 1954. I’m taking more time than I wanted to so I’m going to
skip over this quickly, but it’s interesting to notice that there was in fact an analog control
alternative that went on for some years; the idea was simply to automate manual calculations
to some degree with calculating aids, and pretty much use the old system.
So, the project that we just saw the movie about was SAGE, the Semi-Automatic Ground
Environment. It was a radar-based early warning system that used centralized, networked
computer control. SAGE was deployed between 1958 and 1961. There were actually, I think,
23 sectors, and the original vacuum-tube computers—the last one was finally taken down in
1983, still operating. The total cost of the system is hard to calculate, but it was somewhere
between four and twelve billion dollars, in dollars of around 1960, which would be about five
times that much today, so really, quite a bit of money.
The SAGE Direction Centers, which you saw briefly during the film, were four-story
concrete blockhouses. They had their own power plants, partly because the power grid might
go down in the event of a war, but mainly because the machines took so much power: they
had an entire floor devoted to air conditioning. One floor was devoted to the two duplexed
computers. We already heard the statistics of the enormous size of the machine.
One effect of SAGE was the enormous contract that IBM got for building the SAGE
computers; they received about 500 million dollars during this period, to build the 56
computers. It was the single largest contract IBM had in the 1950’s.
This is unfortunately a little hard to see, but this is a block diagram of the SAGE Direction
Center. This up here, the top floor is the control center; I think this floor is the computers,
and down here is air conditioning and off here to the side is the power plant and its cooling
towers. Here’s an interior of the SAGE control room. We’ll skip through these quickly since
we’ve already ... the monitors gave off a blue light, and they were sometimes called “blue
rooms” because of this strange glow that they emitted.
SAGE was responsible for many, many technical advances, perhaps more than any single
computer project: magnetic core memory I already mentioned;
Forrester’s highly improved vacuum tubes which were much more reliable than those that
existed before; the operationalizing of duplexing—linking the two computers together so
they would share data and one could go down and the other one would continue. The total
downtime of SAGE computers was somewhere between one and ten hours a year. This is in a
period when most computers were down for numbers of weeks, or even months, all told.
SAGE was responsible in part for digital data transmission over phone lines; for solving all
kinds of problems in analog/digital conversion; the use of modems; it was, in a certain sense,
a network—all the Direction Centers were linked, and shared data about their immediate
situations so the overlap problem could be solved; video displays, as you saw in the film;
graphic display techniques; and, maybe most important, real-time digital control. Again, not a
use most people thought of in this period.
He was also responsible for the first algebraic computer language; the first real-time
software. The programs written for SAGE were enormous, by the standards of that day, and
even by today’s standards. The first operational program in 1958 was about a quarter of a
million lines of code—the most complex system ever built—and one of the interesting
problems faced by the SAGE designers was how to organize people to write such a program.
By the early 1960’s in some of the spin-offs from SAGE these systems were up to a million
lines of code. James will talk about the Systems Development Corporation, I assume, but
this was a spin-off of the RAND Corporation in Santa Monica that did the programming for
the SAGE system.
At its peak this effort had 800 programmers, which doesn’t sound like a lot by today’s
standards, but at that time, by some estimates, this was about 20% of all the programmers
in the world. [Laughter] It was the largest programming effort of the 1950’s, and it was
extremely influential: many people left SDC or other SAGE programming efforts and went
on to found their own companies, and spread knowledge.
This is the cover of the IBM manual for the SAGE computer.
I’m going to close by talking a little bit about SAGE as a cold war product and a cold war
social project. The issue of air defense for which SAGE was developed gave the project a
sense of urgency which it would not otherwise have had. That meant in turn that there was
almost unlimited funding available for this, and we can wonder what would have happened had
that Soviet atomic bomb never gone off. The problem it was trying to solve— the problem of
nuclear command and control—was an extremely difficult problem. As the cold war dragged
on and it became obvious that this meant basically 24-hour, 365 day a year, permanent alert,
the rationale for using a computer to do this control became more and more telling. These
machines had to be extremely reliable—being down for even an hour is a problem in a
situation like that. Nuclear command systems must be centralized, because of the issue of
renegades—people taking off with their own weapons. And finally, of course, the machines
must operate in real time.
It’s an interesting project to look at because one might think that the agency behind this
effort was the Air Force. In fact, it was not. It was the group of scientists and engineers,
many of them from MIT and RAND, who really pushed this project through. There was
actually a great deal of resistance, especially at the higher levels of the Air Force, to SAGE
for many reasons. The most fundamental reason was the strategic issue I mentioned before.
Since the Air Force did not expect to need SAGE, it was hard for them to really back it.
What happened was a process of mutual orientation, in which the civilian engineers educated
the Air Force about the potential of these new machines, and in turn the military funders
directed the engineers toward this particular solution to that problem.
SAGE was extremely successful, at least in this sense: that by the time it was over, the Air
Force had been completely transformed from a group that initially resisted computerization
to the leading advocate of computerization within the military. SAGE has a lot of legacies;
many of them are technical, and we’ll hear more about those in a minute. One of them was
more computer control systems for the military: there were something like 25 other
computerized command and control systems being built in the late ‘50’s and ‘60’s, as soon as
the SAGE systems became operational. One of them is the Strategic Air Command Control
System, the World-Wide Military Command and Control System, and in fact, if you look at
the Strategic Defense Initiative of 1983, it’s really just SAGE all over again, with a
different set of weapons.
There are also some ironies about SAGE. It was almost obsolete by the time it was
completed, because ICBM’s made its warning abilities superfluous. It probably would not
have worked: it was easily jammed; many of the tests of the system were fudged to make it
appear that it would work, but it probably wouldn’t have. And the Air Force, as I said,
initially didn’t want it.
But SAGE did work in many other ways. It worked to build a computer industry. It worked to
justify air defense. It transformed the Air Force into a high-technology force. And maybe
socially most important, it created what became a very long-standing belief that there was a
technological solution to the problem of nuclear war. I’ll stop there. [Applause.]
JAMES WONG:
My name is James Wong, and I’m going to try and tell a story about my life with SAGE. I
want to first thank Dag for inviting me to speak about SAGE here. In the last three or four
weeks, thinking about SAGE and trying to get a memory dump, it’s like going home, really,
back to SAGE. Unfortunately— if I knew I was going to be standing here today, 20 years
ago, I would not have cleaned out my attic and threw all those documents away! [Laughter]
So much for being a packrat, right? I did save them for 20 years though, right?
[Laughter]
Anyway, by this time you know that Lincoln Lab was the birthplace of SAGE. Lincoln Lab was
chartered to be an R&D organization, so they consented to start the software development
if some other organization would pick it up and do the development and, later on, installation
at all the sites. The Air Force looked around to find somebody, and the only logical choice
was the RAND Corporation, because RAND had a lock on the programmers in the country.
RAND had about 10% of the programmers, and that was 25 experienced programmers.
[Laughter] So the industry experts said at that time there were like 200 experienced
programmers. So we were the logical choice.
So this was 1955, and I was very fortunate to be one of eight people as the nucleus to go
back to Lincoln Lab to work with them, and the objective was to pick up the programming
function, transfer it from Lincoln to RAND Corporation, and then move it out here to the
west coast in Santa Monica. So that was the key. The original commitment [was] 25
programmers, and the agreement with Lincoln Lab was, we would be working together as one
organization, and the RAND programmers would be integrated into the Lincoln organization.
And here we were, back on the east coast, full of vim and vigor, young, idealistic, ready to
conquer the world. Remember, at that time the chill of the cold war was on, so there was a
lot of anxiety at that time. And here we were, back east, out of our environment actually
because we were all from the west coast. And our motivation—what was our motivation? I
guess we had quite a few. First one was, we’re going to protect the country. The second one
was, we’re going to be doing something that nobody has ever done before. A third thing was,
we want to prove the skeptics wrong—those who said this was a Mission Impossible. And,
that’s our motivation for going into this thing.
I remember the first time I walked into the computer room at Lincoln Lab, and this is what
I encountered: it’s awesome! Cabinets upon cabinets of vacuum tubes, and I think Paul
mentioned there was something like 58,000 vacuum tubes, something like that, and it’s mind
boggling! How can so many vacuum tubes be working without some sort of failure? You know,
it’s really mind boggling. And then we were told, “Hey, it’s only a simplex machine here, in this
lab. Out on site you’re going to have a duplex computer.” So you can imagine. And you walk
around the cabinets, you just feel like you’re engulfed in there. You get a strange feeling
that you’re part of the computer, and the computer is part of you! It’s like a member of the
family.
It’s sort of weird, when you get right down to it.
From there, my first assignment, since I had an electronics background, was to work with
the equipment team to check out the long-range radars, the gap-fillers, the ground-to-air
data link, and the height-finders. And my specific assignment was to write a test program to
check out the ground-to-air data link. Two Bell Labs employees were assigned with me to
work on this program, and at that time everybody really worked hard. Everybody: Lincoln
Lab personnel, as well as RAND, and Burroughs people involved, IBM, and RCA. There were
many, many organizations involved. So there wasn’t just a few companies involved in this
thing.
We worked about three weeks, and finally we got the program written, got it keypunched,
and we were ready to assemble the program, and make a run. In those days, computer time
was real tight, so if you want to do an attended run, you have to run from midnight to dawn.
If you want unattended runs you can submit your runs and they’ll run them for you during
the daytime. Since the Bell Labs people and I decided—we had like a pride of authorship in
this computer program—we wanted to see it assembled and run firsthand. So we scheduled
time at midnight. We all agreed we would show up 10 minutes early; so that in case something
goes wrong we still can get our time in. At the appointed day, about five minutes to twelve, I
would come running into the computer room with my deck of cards, and I decided to play a
little joke on my friends. I come running in the computer room, and pretend I tripped, and
fowwww! All the cards were on the computer [room] floor, right? [Laughter] You should
have seen my associates! They were down on the floor trying to reassemble the deck! Of
course they couldn’t do it, because even though the deck was sequenced, some of it, we had
made changes to it and inserted cards in between. In those days, we had one card per
instruction; you had the ops code, and the address, and that’s what it was. After scrambling
around for awhile, I went back to the back of the cabinet and brought out a duplicate deck
You should have seen the faces on those guys! [Laughter] I almost got killed for that one!
[Laughter]
So, everybody worked hard, but everybody—there were a lot of practical jokes going
around, too. It made the things lighter, and just eased the tension some. But those were the
days—they were really heavy days. Schedules were tight, and everybody worked day and
night. We were not getting compensated either, at that time, for working overtime hours.
My next assignment: once again I was very fortunate to be involved with this one. I was
assigned to what was called the Program Executive Control, the most important program in
the SAGE system. [In] today’s language that would be called the operating system. The
operating system, PEC it’s called, was designed with a radar sweep of 15 seconds in mind. In
the computer it was called one frame of data. The Executive was broken down into three
sub-frames, so you have five seconds each sub-frame. Program modules would operate in the
first sub-frame, a different set of program modules can operation on the second sub-frame,
and the third sub-frame had a different set of modules. Lincoln Lab was very ingenious in
many of their designs and their concepts, and this is one of them, this Program Executive
Control.
A second one is the compool; as the name implies, it’s a common pool of data that program
modules would use. They would either put data into a particular location, later on another
program might use that information. So the compool was another innovation; as a matter of
fact the COBOL compool was based on the SAGE system. A third innovation was called PTRS,
Program Test and Recording System. Everything run in the SAGE program was recorded on
tape, and the tape can be later dumped for analysis.
At that time period the biggest problem we had, since this system was a huge system, first
time put together, the requirements specifications were vague and incomplete. At that
time—we all know this: if you don’t nail down requirements [laughter], if you have three
programmers you’re going to have three different interpretations, right? So, that’s the
problem we faced. The specifications [were] called in those days, I remember, it was
opspecs and mathspecs. Those were the requirements specifications. And on top of that,
they were classified, Secret or Confidential, so difficult to get to in the first place.
[Laughter] So the priority at that time, before you can start writing coding specs and
writing code, was to get the opspecs and mathspecs tightened up, so that everybody is on
the same page. That was one of the biggest problems involved; that means schedules were
slipping, and it’s an interesting thing, because all the programmers were sitting in one room
trying to get these specs together, and we looked at each other and say “Who ‘s doing the
work back at the office? There’s nobody back at the office doing anything.”
From there, putting the programs together—many, many program modules, as I remember
something like 90 to 100 program modules that take care of the radar input, the
identification functions, the weapons assignment function, the switchover from computer to
computer—there were about 90 to 100 software modules.
From there, this is now getting into 1957. Did I get the dates right?
Yeah.
It was time now, the programs were being checked, and it was ready to move the program to
McGuire [Air Force Base, New Jersey], to check out the McGuire SAGE site. I was one of
the team leaders, to lead the team out there. The interesting question that came up at that
time was: can we test and integrate new hardware, new software, and new procedures at the
same time? Nobody had an answer. So what I called the massive manning concept was
applied. [Laughter] We had 70 programmers out on site. Everybody—people were working
day and night, constantly, because computer time was in short supply. Because other
organizations were using computers as well: IBM, Burroughs, RCA, and other organizations
were using computer time also.
Getting out on site, now. We anticipated problems, of course, and every time a problem
showed up, our programmers would say, “Hardware!” [Laughter] Hardware people would say,
“Software!” [Laughter] So there was a lot of finger-pointing going on, because there was a
lot of problems. [Laughter] Fortunately, at that time IBM had a very liberal awards program
for the engineers: if the engineers can come up with a fix for a problem in the hardware,
depending on the complexity of the problem, they would get awards.
The nominal awards were like $50 and $100, and it went up to $1,000 to $15,000. I
remember, as soon as that 15 [thousand] dollar prize was awarded to somebody, those
engineers came over to us and said, “Would you help us isolate this problem, and develop a
fix for us, and we’ll share the awards with you.” [Laughter] There was still finger-pointing,
but they were friendly finger-pointing from then on! [Laughter]
This is getting to be the latter part of ‘57, now. There were some changes going on back at
RAND headquarters. The System Development Division of RAND, which was responsible for
SAGE, had grown so big that it was like the tail wagging the dog. And RAND had the same
kind of problem that Lincoln had.
RAND was chartered also to do long-range research. So they didn’t want to do the
production and installation. So they spun off the new organization, called System
Development Corporation, so one day I was working for RAND, the next day I was working
for SDC. So that’s the way it was. Also at the same time, toward the end of ‘57, the SAGE
computer came to Santa Monica. That would be now the test-bed for development and
maintenance of future software. I was fortunate enough to take the team from Lincoln back
to Santa Monica; checked out the computer, and from that point on, the official handover of
the software function from Lincoln to RAND was complete.
We’re going up to 1958 now. In June of 1958 McGuire went on-line. That’s just about two
years after the equipment arrived on-site, at the blockhouse over there. Now Stewart Air
Force Base [New York] was the next SAGE site to go on-line, and that went on in September
of the same year, ‘58. They needed only 40 programmers to do the installation. Subsequent
sites went on-line about every two months, until 1961, when all the SAGE sites were
completed. For those sites, they needed only 15 programmers. So we went from 70 to 40 to
15. I guess in all—I think Paul mentioned there were 20 sites—I think we had a count of 20
Direction Center sites, four Combat Center sites, one combination Direction Center and
Combat [Center] site, and that was up in North Bay, Canada—that’s the computer that’s the
combination Combat and Direction center site. As a matter of fact, I have a friend back
here, Dave Burley, he was at North Bay, Ontario, and I’ll bet you he can still find his finger
marks on some of those knobs! [Laughter]
Paul mentioned that SDC had really launched programmers into the computer industry, and
it’s very true. At the height of—SDC must have trained over 2,000 programmers. Paul
mentioned also that we had like 400 programmers at any one time, that’s about right, the
right ballpark. Half of it was at home, doing the modifications, the other half was on site
supporting the installations. And of course, by that time, the other half was in industry,
which is about another 800. Many of them, like Paul said, started their own companies,
became managers of data processing organizations. They really cut their eyeteeth on SAGE,
all these programmers, all these managers.
The word around the industry was, “It was first done in SAGE.” For many, many years those
were the words said in industry. SAGE was the real-time, command and control computer-
based system with capability so advanced that 40 years later, today, some of that capability
can still be called state of the art. The computers today are a lot faster, and better, but we
think about things like multiprocessing, real-time database management, distributed
processing, time sharing, interactive displays, networking— they were all there in SAGE.
That concludes my talk. Thank you. [Applause.]
Can I just say one more thing? Dave Burley, my friend, found this [document] in his files, so
if anybody wants to come up and take a look—it’s the data flow in the computer system. So if
anybody wants to come up and take a look at it, they’re welcome to, and I’m sure Dave can
answer a lot of their questions. Dave has also generously—he’s going to contribute this to
the museum. [Applause.]
Q. [Inaudible]
JAMES WONG: How does anything else like this sneak into industry, right? [Laughter] I
think we’ve all heard about the other world, and all that information has leaked out to
industry [inaudible].
Q. In your talk you discussed the fact that when you started off you had loose
specifications, and you had the hardware people pointing at the software people, and
software people pointing at the hardware people. I’m glad to see that after 40 years,
nothing’s changed! [Laughter] [Someone else: We haven’t learned too much, have we?]
LES EARNEST:
Hi. I sat down this afternoon to write up some of the war stories just to focus. I called this
SAGE a marvelous technological solution to the wrong problem. There are many more war
stories than we can have time for this evening. But let me go over a bit of it.
I admired the MIT computer work from afar, initially. When I got out of Cal Tech in 1953 I
knew that I would have to go into the military in some way, because they had tried to draft
me already. I found that I was uniquely qualified for a special program in the Navy: I had an
engineering degree and poor eyesight. If I had been lacking either of those I couldn’t have
qualified, but this somehow got me into the Aeronautical Computer Laboratory, in Johnsville,
Pa., where we had the world’s largest and fastest computer of that era. It was called
Typhoon. It was an electronic analog machine, built by RCA, and it needed check solutions, so
my responsibility, as digital computer project officer, was to generate check solutions on an
IBM CPC, an electromechanical computer that was a real bear to get anything to work on. It
only had 40 words of storage, which was electromechanical, and you had to give it exercise in
the morning to get the oil flowing, or it wouldn’t work. [Laughter]
While there, I began to hear about this Navy-supported project at MIT that produced
Whirlwind. What would happen was, the admirals would go to MIT, would listen to what they
were told by Forrester and others, took careful notes, but they didn’t quite understand
what this was all about. So then they would come to our lab, and would talk to my boss,
Commander B., ask him what this means. He would then at lunch time come to talk to me, and
ask me.
I would give it back to him, he would give it back to the admirals. [Laughter] Over time I
began to find ... it was really whiz-bang stuff. I was intrigued by all of this.
So when it came time to escape from the Navy, I applied to several places.
I
was offered a couple of jobs at IBM, but I chose to go to MIT Lincoln Lab, and somehow I
ended up in the Weapons Integration Group, which was responsible for making manned
interceptors and missiles fly under SAGE control. We had to develop the equations for
guidance, and we designed the Intercept Director’s console, and that sort of thing.
It was all great fun. James mentioned that he did the data-link. Initially, commands to the
interceptors were sent by voice radio. You’d tell them which direction and how fast and at
what altitude to fly. This data-link of course automated that, so the computer could give the
directions on a little display in the cockpit. The specs for that were all very carefully worked
out, to show how many bits for each function, and the identification code, and all of that. I
sort of expected you to mention a small problem that arose: there was one contractor that
build the transmitter system, and another that built the receiver, and whereas they all
agreed about how many bits for what, they didn’t agree on—there was no spec on which was
sent first, the high-order bit or the low-order bit. [Laughter] Sure enough, Murphy’s Law
got ‘em, so they got to redesign one of the systems, I forget which one. [Laughter]
One of our early tasks was to bring the Bomarc missile into SAGE control. Bomarc was a
rocket-assisted takeoff; it took off vertically, would get up to speed, then would be powered
by a ramjet, would heel over, fly at high altitude with a Doppler radar looking down.
Presumably, when you told it when to look, it would find a bomber down below and would dive
and kill it. That was in theory. [Laughter]
Well, it was a pretty complicated beast, and of course it was necessary to test the
electronics of the missile when it’s sitting on the ground. So they had a test mode for the
missile complex, in which you throw a switch to test, and then you can send simulated firing
commands to the various missiles and you check whether they received them and
understood, and all that. But of course it doesn’t cause the missile to fire, it just is testing
the electronics. Well, when we were asked to review this, one of our engineers looked very
carefully at this system, and discovered that if you send the missiles the test commands,
and then throw the switch from Test to Operate, without individually resetting each missile,
they will all erect and fire. [Laughter] As soon as we mentioned this to Boeing, they quickly
concocted a fix for that.
A year or so later I somehow was selected to lead the team that obtained nuclear warhead
certification for the Bomarc missile, so we had to go through all the hardware and software
and prove that the probability of failure—combination failure of anything—would produce an
inadvertent launching, with probability less than 10-to-the-minus-very-large-number on any
given day, and that it would take at least two berserk people to do it by themselves; that is,
one person couldn’t do a launch.
Well, we were able to convince ourselves eventually that it was okay, but along the way we
discovered a rather frightening thing about the way it worked. All the telephone lines from
the computer out to the launch sites were duplexed for reliability, so if one goes down you
have another way of issuing the launch commands. All of SAGE was built that way, with
backup and redundancy. So, at the far end of the line, there’s a little black box that listens
to the primary line, and if it senses that that has gone bad, it automatically switches to the
backup. Unfortunately, we discovered that if the backup is also bad, what it does is amplifies
the noise and generates a random bit stream. [Laughter] So one of our guys did a Markov
analysis to figure out how long it would take to get a firing command; it turned out to be a
little over two minutes. [Laughter] However, in order for the missile to actually launch, it
has to get a full set of commands—that is, direction, speed, altitude, in addition to the firing
command. And it had to get this within a certain length of time. We were able to show that
the probability of getting all of that stuff within the required time frame was very, very
small, very unlikely. Therefore the effect of this would be, the missile would erect, and then
abort. I published an analysis of this with the provocative title “Inadvertent Erection of the
IM-99A.” [Laughter] As luck would have it, two weeks after we released the report, it
happened, in suburban Washington, D.C. [Laughter] So, I promptly found myself to be the
head of a committee to fix that, and it was very easy. You just sensed bad line #2 and then
you shut down.
This was all heady stuff, and we were able to make the hardware work pretty well, but of
course when you backed off and looked at the performance specs, or the lack thereof, you
realized that this was in fact a gigantic boondoggle, because there were no performance
specs in the sense of an air defense system—that function. There were literally no
requirements of being able to meet a manned bomber threat of any sort. Paul mentioned the
jamming. That would kill the system in an instant. It simply could not track bombers that
were dropping chaff and actively jamming. There were later some hacks at trying to make it
work in that kind of environment, but they were just that. And a much simpler system could
have been used in that kind of environment.
If that weren’t enough, however, there were certain other things that would have
contributed to its downfall in a real war. It was basically a peacetime defense system—it
worked fine in peacetime. [Laughter] MIT had recommended from the beginning that these
big computer facilities be buried underground so they would be reasonably well protected.
The bean-counters in the Pentagon, though, saw that that was a big expense, to put the
stuff underground, so they said, “Well, let’s just put it in a concrete blockhouse.” Then it
becomes a lot more vulnerable.
But the killer on all of this was that the Air Defense Command wanted a good lifestyle; they
knew that their officers would have to spend a lot of time in these facilities. They looked
around at where there are good facilities. At that time, General LeMay of the Strategic Air
Command had the best of everything. He had the best officers’ clubs, everything was
topnotch for SAC. So they put most of these computer facilities or a large fraction of them
at SAC bases, where they all became bonus targets. [Laughter] Obviously, if there was a
manned bomber attack, they’d go for the SAC bases first, and they’d get the air defense
system as a byproduct. [Laughter] So it was not a wonderful air defense system.
In the same era, the Air Force intelligence was producing claims that the Soviet Union was
developing an air defense system of a similar sort, but somehow it never materialized. I
don’t know whether that was because they really weren’t up to it, or whether they really
understood better than we did what it would take.
But then there was this wonderful facility in SAGE, the display room with glimmering blue
consoles and subdued light. And it became a showcase for both the brass, and all the
military, and also congressmen. Everyone decided that this is the way to run a war. This gave
rise to this whole industry of L-systems, so-called, 438-L, 465-L, all this stuff, that were
competing for funds with other things. And for the most part, none of them worked worth a
damn. There were a few exceptions: the satellite control system, I would say, was very
effective, and provided good intelligence. But most of these others, including the Strategic
Defense Initiative, were basically boondoggles, and we ain’t through it yet! This stuff is still
going on. It gave rise to a multi-billion dollar industry that basically produces useless junk.
And here we are, 40 years later, still at it. [Comment: talking about it.] Right. No—still doing
it, the government’s still doing it.
Anyway, once over dimly. Thanks. [Applause.]
PETER NURKSE:
What we’ll do now is have the three members of the panel take the seats here and—why
don’t you use this microphone, and pass it between you as you [inaudible] as you answer
questions. And if you repeat the audience’s questions—you in the audience can remind the
panel [inaudible] otherwise your questions won’t be recorded.
Q. Aside from assembly language, what was the other language used to program the
computer?
JAMES WONG: Basically that was it, assembly language. Later on, late, they tried to put
JOVIAL—tried JOVIAL as the language. Anybody know about JOVIAL? It’s a higher-level
language, but it was not cost-effective and it was never put in.
LES EARNEST: Let me just comment. It might be mentioned that this was a fairly peculiar
computer in some ways. It was schizophrenic: it had a split accumulator that was thought of
as being x-y coordinates for geographic things, and indeed it worked quite well on that sort
of thing. It turns out, though, that most of the computation was not of that nature, and
therefore this structure, the architecture, didn’t make a whole lot of sense.
Q. Did it have MMX too? [Laughter]
JAMES WONG: I guess that I didn’t mention that this was a 32-bit machine. The left half
was the ops code, and the right half was the address. So that was basically it.
Q. How much memory?
JAMES WONG: That’s right. [LES EARNEXT: 64K.] Yes, it’s 69K actually, they added on—
that box right there I believe is only 32K; there were two boxes, and they added another 4K
later on, so it was 69K. Actually, this system is really a drum system; there are 12 drums. If
you go back there you can see them back there—there are a few back there now. The
capacity was 150K words. Can you imagine? Today it’s what, gigabytes? But in those days,
that was really something.
Q. What was the cycle time?
LES EARNEST: Six microseconds.
Q. Did any of these concepts get into the FAA air traffic control [inaudible]?
LES EARNEST: Well, yes. Mitre, the spinoff from MIT, did get into the FAA system
development business about five years after SAGE went operational, and produced some of
the kluges that are now breaking down, I guess.
JAMES WONG: In addition to this, IBM was the prime contractor for the FAA.
PAUL EDWARDS: I just wanted to mention one other very important spinoff of SAGE, was
the SABRE airline reservation system. SAGE stands for Semi-Automatic Ground
Environment; SABRE stood originally for Semi-Automatic Business Research Environment.
[Laughter]
Q. [Inaudible]
PAUL EDWARDS: The question is, how the source code was stored.
JAMES WONG: The program was actually on mag tape. The mag tape, when you started up,
is read into the computer, and it’s stored on drum. Except for the Executive, and a few of
the programs that you need, that would be in core.
Q. [Inaudible]
PAUL EDWARDS: How are different versions ...
JAMES WONG: Versions of the software? [Inaudible] That is called the modification,
right? And design change control was a huge problem in those days. Of course, software
programs are never finished. It goes on and on and on and on. And, yes, what happens is, if
there’s a fix that had to be made on site, the site programmers would make the fix, but they
were not allowed to mess with the master tape that came from home base. But they could
actually run their changes, and then submit the change back to home base so they can
integrate it into the whole system. That’s a continuing process. If it’s not an emergency fix,
they would accumulate a whole bunch of fixes and they would then produce a new mod of the
software and that would go out to the sites.
LES EARNEST: That was typically many months between, as I recall.
JAMES WONG: Yes, that’s true.
Q. What was the prevailing view of yourselves, back then, about the pace of technology? Did
you get any [inaudible] would be obsolete? [Inaudible] back then?
JAMES WONG: I guess you’re saying, how did we view...
Q. Did you think by the time you worked on SAGE—did you think that by the time [inaudible]
in all 22 centers [inaudible] incredibly obsolete, much better stuff, or did you think this
would be state of the art for a long time, or...
JAMES WONG: You have to remember: we were young, and innocent [laughter], and we
didn’t know what we were doing! We were really flying by the seat of our pants. We were
just working to get the system working, and there was not enough time to think ahead, to
see what would happen in a few years. That was basically it.
LES EARNEST: I came into Lincoln Lab in a somewhat different mode than most of their
employees: I actually knew how to program. I think I may have been the only person they
ever hired who knew that. My office-mate initially was a specialist in radar data—he called it
radah dater, being from Boston.
I
asked him—I’d been an aviation electronics officer for three years, and I knew a little bit
about electronic countermeasures, so I asked him, “Well, what do you do if they jam?” He
said, “Well, we shut down.” [Laughter] I knew—this was my first week on the job. I knew
from that point on that this was a fake. Somehow I stuck with it for five years or so, before
I wandered off. It was a somewhat disillusioning experience, I would say.
Q. Since we hear that there was some number of thousands of vacuum tubes, and another
certain thousand transistors, why were you using vacuum tubes, if you had transistors?
LES EARNEST: We didn’t have transistors initially. And they certainly weren’ t suitable for
all of the applications. For example, the core memory, you needed big, humongous drivers to
run the core. Tubes were it, in that era. Later, the beefiness came along.
Q. [Inaudible]
PAUL EDWARDS: I think that figure probably comes from the fact that there was going to
be a second generation SAGE computer that was transistorized, and one system was built
and installed. But at that point it became very expensive and they abandoned it.
Q. You were talking about—Les was—the Russians maybe doing something. Do we know
anything more about, not only what they did, but did we have allies who were aware of what
we were doing, and wanted a similar system in Europe, or—how global was this kind of
program?
LES EARNEST: As I remarked, I think that was really intelligence propaganda.
That is, the Air Force—as you know, the services’ intelligence agencies often perform to
meet the objectives of the organization. It might be mentioned also that in another sense
SAGE was really the Air Force’s response to Nike, another air defense system being
developed by the Army. The Air Force figured they had to outdo them, and they succeeded
in that Nike eventually was integrated into SAGE. That is, SAGE became the dominant
partner, even though it didn’t work.
PAUL EDWARDS: That’s an interesting question, and Les’s response is right on. There were a
lot of contests within the military about who should handle air defense, and it was again this
issue of, what is this problem—are we waiting until they get here, and then shooting them
down, or are we trying to do something further out, before they actually reach U.S. soil? So
the Army response was, air defense is like artillery: we shoot them as they come in. There
were systems like this built for NATO, and several other NATO countries adopted similar
systems. I don’t know very much about the Russian air defense system, but my impression of
it from the only source I found on that subject, was that it was extremely decentralized.
Which is a very interesting contrast. Here in the U.S. we have a decentralized society and an
extremely centralized air defense system; the Soviet Union has one of the most centralized
governments in the world, and ends up with the most decentralized air defense system, in
which basically everybody shoots at whatever is coming in when they see it. [Laughter]
Q. How did you debug [inaudible] tools, debugger,
[inaudible]?
JAMES WONG: Basically we didn’t have any tools; it was just running your program and see
if it runs. If it doesn’t run, you go back and sit at your desk and do it again.
Q. [Inaudible]
JAMES WONG: Yeah, it halts, or you get the wrong answer—that type of thing. As a matter
of fact I have a good story to tell you about that one. Working with programmers, way back
in RAND, I learned a lesson. Any time a programmer tells you, “This program’s gonna run
100% this time,” bet him a dollar. You’re going to win every time! [Laughter]
Q. Did you do your program development on the SAGE
system itself?
JAMES WONG: The development was done on what was called the XD-1; that was the
prototype of the SAGE Q-7, out on site. There were actually two development centers: one
was at Lincoln Lab, with the XD-1, and the other one was at Kingston, the XD-2. So we used
both those sites for development.
LES EARNEST: The XD-1 was a simplex system, wasn’t it? [JAMES WONG: Yes.]
That is, there was not duplex, to switch.
Q. This [inaudible] here, wasn’t there something about Polaroid cameras being used for
debugging? That was a story that was told to me by an SDC employee, that they had Polaroid
cameras—the story I heard was that they had a Polaroid camera mounted in front of the
console, and if the system crashed they would take a picture of the lights on the console and
give that....
JAMES WONG: Yeah, you’re right, 100% correct. That was one of the things, that’s it as a
matter of fact.
Q. When the Nike system was, quote, integrated into the system, what had to be changed?
Were there software changes, or hardware changes, or ...?
LES EARNEST: It was mostly software. Of course there had to be a digital link connecting
the Nike site to the SAGE site. But that was minor, compared with the software that had to
be done to hand over targets to them and lay it on them.
Q. Did this system have the ability to launch without human intervention, or was it always ....
LES EARNEST: No. No, always required two levels—the question was, was the system able to
launch automatically, that is, without human intervention. No, the Weapons Director had to
designate the target, hand it to an Intercept Director, who would then launch a missile or a
manned interceptor to get it.
PAUL EDWARDS: That was, however, contemplated by the designers.
Q. Was BMEWS ever integrated with the SAGE?
PAUL EDWARDS: Was BMEWS ever integrated with SAGE? Yes, I think.
LES EARNEST: The information flow, yes. It was not automatic.
Q. [Inaudible]
JAMES WONG: Yeah, the radar data came in from the DEW Line into the Direction Centers
located in the northern part of the U.S. The radar data actually came in from the DEW Line.
Q. What sort of data rates were these land links, for the
phone lines?
LES EARNEST: I don’t have a clear recollection.
Q. I wonder if you could confirm, or say this story is garbage, that I heard, that at some
point they tried directing manned interceptors directly from the SAGE computers, and for
the first test, it told the plane to make a 90-degree turn, and from then on the pilots would
never turn that on again?
LES EARNEST: I don’t recall hearing the story in just that form. The
initial—excuse me, the question, he heard that the computer told the
pilot to do a 90-degree turn instantly, and they realized they couldn’t do
it. Well, it is true that the initial versions of the guidance program did
not take into account the turning radius of the interceptors. They would,
of course, servo into about the right direction over time, but there was an
improved version of the software that was developed that took into account
the minimum turning radius of the interceptor to get it into position. If
you’re planning to make a broadside attack, which is one of the kind where
you want to come in at an angle off the beam of the bomber, you have to
come to a certain position, do a turn and then come in. That obviously cannot be
done on a dime, so this improved version that took into account the turning
radius did a better job.
End of transcript.