Status of the Release of the New IMP System (2600)
A June 1972 progress report on repeated attempts to switch the ARPANET to the new IMP system, release 2600.
Walden, D.C., "Status of the Release of the New IMP System (2600)", RFC 359, DOI 10.17487/RFC0359, June 1972, <https://www.rfc-editor.org/info/rfc359>.
@misc{rfc359,
series = {Request for Comments},
number = 359,
howpublished = {RFC 359},
publisher = {RFC Editor},
doi = {10.17487/RFC0359},
url = {https://www.rfc-editor.org/info/rfc359},
author = {D.C. Walden},
title = {{Status of the Release of the New IMP System (2600)}},
pagetotal = 1,
year = 1972,
month = jun,
} RFC text
Network Working Group Dave Walden
RFC #359 BBN
NIC #10601 22 June 1972
Category: B.1
Obsoletes: RFC #343
I M P O R T A N T
=================
HE STATUS OF THE RELEASE OF THE NEW IMP SYSTEM (2600)
We have still not managed to get the new IMP system up.
To recapitulate:
We tried the first time May 15; but, completely under- estimating
the difficulty of distributing the new system to over twenty-five
sites, we never even got around to debugging the system.
We developed a suitable distribution mechanism and tried again
May 31. This time we got to debug the new IMP system and found a
number of problems which precluded leaving the new system up.
Trying again June 6, we got the new IMP system up and working
quite well, but the version of the TIP system which runs with the new
IMP system wouldn't work hardly at all. So we put the old systems
back up again.
The day before yesterday, June 20, we tried again. The IMPs and
TIPs loaded and seemed to fly quite well, so we left the new systems
up. But by yesterday, June 21, afternoon, with crashes happening in
TIPs at the rate of about one per hour, we backed off again and put
the old systems back up. (One TIP crash per hour in the network means
there is about one crash every eight or ten hours debugging with one
TIP which makes it nasty to debug.)
We plan to skip Tuesday, June 27, and Tuesday, July 4, and to try
again Thursday, July 6 (1972), and if necessary, again on Tuesday,
July 18, and following Tuesdays, as per RFC #343.
DCW/jm
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by BBN Corp. under the ]
[ direction of Alex McKenzie. 1/97 ]
AI ELI5
On this page
§1Still Not Up
Dave Walden of BBN opens with a blunt headline: the new IMP system (2600) is still not up. The RFC is dated 22 June 1972, is marked Category B.1 and obsoletes RFC 343.
The text recaps what has been tried so far and says what comes next.
The message starts by saying the new software is still not working on the network.
§2The Failed Attempts
The RFC lists four tries:
- May 15: the team badly underestimated the difficulty of distributing the system to over twenty-five sites and never got around to debugging it.
- May 31: with a distribution mechanism in place, they debugged the system but found problems that prevented leaving it up.
- June 6: the new IMP system worked quite well, but the matching TIP system hardly worked at all, so the old systems went back up.
- June 20: IMPs and TIPs loaded and flew well and were left up, but by the afternoon of June 21 TIPs were crashing about once an hour, so the old systems were restored.
They tried four times. First it was too hard to hand out the new software, then it had bugs, then one half did not work, and finally things kept crashing every hour.
- 1972May 15: first try, distribution too hard
- 1972May 31: debugged, problems found
- 1972June 6: TIP system failed
- 1972June 20: left up, backed off June 21
§3The Plan for Next Tries
The author plans to skip Tuesday, June 27, and Tuesday, July 4, and to try again on Thursday, July 6 (1972). If needed, the next try is Tuesday, July 18, and following Tuesdays, as set out in RFC 343.
The note explains why TIP crashes hurt so much: one crash per hour across the network means roughly one crash every eight or ten hours when debugging with a single TIP, which makes the bug hunt nasty.
They will wait a few weeks and try again on a set day. Finding bugs is slow because a crash only shows up on one machine every eight or ten hours.