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@ieee.org> wrote:

THIS IS SO COOL!!

aps@dec-marlboro
aps@rand-ai

Begin forwarded message:

> From: Aharon Robbins <arnold@skeeve.com>
> Subject: [TUHS] off-topic: resurrecting the IMP
> Date: December 1, 2013 1:18:26 PM PST
> To: tuhs@tuhs.org

>
> Hi all.
>
> This may be of some interest. From a friend at Utah:
>
>> 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@minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
_______________________________________________
TUHS mailing list
TUHS@minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs