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:


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