2 Dec
2013
2 Dec
'13
3:36 p.m.
+1
As for reliability. The CMU IMP at one time was near one of the big
printer from the PDP-10's and often became a temporary resting place for
something if you had to deal with a printer jam, change paper etc. I have
memories of the time a milkshake got knocked/spilled into the IMP in the
summer of 76 or 77. IIRC: somebody was smart enough to pull the breaker on
the power. Then placed a called to BBN and asked them what to do.
Somewhere I had a picture of a person ??Jim Teter maybe?? acting on the
response in the parking lot: hose it down and the use hair dryers to dry it
out.
It was powered back up and worked and soon appeared a sign about not
putting stuff on the IMP
On Sun, Dec 1, 2013 at 5:54 PM, Armando Stettner <aps(a)ieee.org> wrote:
THIS IS SO COOL!!
aps@dec-marlboro
aps@rand-ai
Begin forwarded message:
From: Aharon Robbins <arnold(a)skeeve.com>
Subject: [TUHS] off-topic: resurrecting the IMP
Date: December 1, 2013 1:18:26 PM PST
To: tuhs(a)tuhs.org
Hi all.
This may be of some interest. From a friend at Utah:
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
Date: Sat, 30 Nov 2013 16:06:25 -0700 (MST)
Subject: [it-professionals] computer history: Arpanet IMPs resurrected
The simh list about simulators for early computers recently carried
traffic about an effort to reconstruct and resurrect the Arpanet
Interface Message Processors (IMPs), which were the network boxes that
connected hosts on the early Arpanet, which later became the Internet.
There is a draft of a paper about the work here:
The ARPANET IMP Program: Retrospective and Resurrection
http://walden-family.com/bbn/imp-code.pdf
Utah was one of the original gang-of-five hosts on the Arpanet, and we
received IMP number 4. Utah is mentioned twice in the article, and
also appears in the map in Figure 3 on page 14.
One amusing remark in the article (bottom of page 7) has to do with
the fail-safe design of the IMPs:
In addition ``reliability code'' was developed to allow a
Pluribus IMP to keep functioning as a packet switch in the
face of various bits of its hardware failing, such as a
processor or memory [Katsuki78, Walden11 pp. 534-538]. This
was so successful there was no simple off switch for the
machine; a program had to be run to shut parts of the machine
down faster than the machine could ``fix itself'' and keep
running.
As happened with early Unix releases, machine-readable code for the
IMPs was lost, but fortunately, some old listings that turned up
recently allowed its laborious reconstruction, verification, assembly,
and simulation.
Arnold
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs