IMP System change notification
News about a failed software upgrade and the plan to try again.
McKenzie, A.M., "IMP System change notification", RFC 343, DOI 10.17487/RFC0343, May 1972, <https://www.rfc-editor.org/info/rfc343>.
@misc{rfc343,
series = {Request for Comments},
number = 343,
howpublished = {RFC 343},
publisher = {RFC Editor},
doi = {10.17487/RFC0343},
url = {https://www.rfc-editor.org/info/rfc343},
author = {A.M. McKenzie},
title = {{IMP System change notification}},
pagetotal = 2,
year = 1972,
month = may,
} RFC text
Contents
Network Working Group A. McKenzie
Request for Comments: 343 BBN-NET
NIC #10422 19 May 1972
Category: B.1
Obsoletes: RFC #331
IMP System Change Notification
As most of you probably know, our attempt to release IMPSYS 2600 on
May 15 (as discussed in RFC #331) was unsuccessful. Briefly, the
primary reasons for failure (all operational rather than programming
bugs) were:
1) The network appears to have grown too large for us to
successfully coordinate operator intervention at all sites.
2) An unanticipated aspect of the gradual release of the new
system was the "poisoning" of IMP's running the new system by
adjacent IMP's running the old system, and vice versa. Working
around this problem made the dissemination of the new system
take much longer than anticipated.
We believe we see solutions to both of these problems and are now
ready to schedule the next attempt(s) to release IMPSYS 2600. We
hereby request all sites to cooperate with this effort in the
following ways.
I. All sites with Model 516 IMP's have been contacted by telephone and
asked to set the switches on their IMP's as follows:
HALT INH - off
W.D.T. - off
AUTO RSTRT - on
MEMORY PRTCT - off
Please be sure that your switches remain set at these positions
until further notice.
II. No site should attempt to use the IMP's "Trace" routine during the
day(s) of the attempted system release.
III. Terminal IMP's may be turned off for significant portions of the
day(s) of the attempted system release. Please be patient with any
inconvenience which this causes.
IV. We hope to accomplish release of IMPSYS 2600 on the next attempt.
Nevertheless, we are not omniscient and may again be thwarted by
difficulties. Accordingly, we are scheduling the next attempt for
Wednesday, May 31, and subsequently every Tuesday (June 6, 13, 20,
...) until the release is successfully accomplished. We will
arrange the release process so that site operator coverage is not
required; nevertheless we hope that the normal site operator
coverage is available in case unanticipated problems develop.
Release of the new system will begin early in the day
(approximately 7 a.m. EDT). We again suggest that sites do not
schedule production work over the network during the release
attempt(s). We will notify each site by phone after the release
has been successfully completed.
Finally, we apologize in advance for any inconvenience caused by
the contortions required to release this new system, and thank all
of the site operations' staffs who worked with us on May 15 for
their cooperation.
AAM/jm
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Ronald de Leeuw 1/99 ]
AI ELI5
On this page
§1The Failed Release
On May 15, 1972, BBN attempted to release IMPSYS 2600, a new version of the IMP operating system, across the entire ARPANET. The upgrade failed. The primary reasons were operational rather than software bugs: the network had grown too large to successfully coordinate operator intervention at all sites simultaneously.
An unexpected problem made this worse: IMPs running the old system interfered with adjacent IMPs running the new system, and vice versa, which the authors called the poisoning effect. This extended the release process much longer than anticipated.
When they tried to switch every machine to new software, the network was too big to coordinate. Also, old machines confused new machines next to them on the network.
§2Coordination Instructions
To prepare for the next attempt, BBN asked all sites with Model 516 IMPs to set specific hardware switches in standby mode: HALT INH (off), W.D.T. (off), AUTO RSTRT (on), and MEMORY PRTCT (off). Sites were told not to use the IMP's Trace routine during the release day, and Terminal IMPs could be turned off temporarily.
BBN scheduled the next attempt for Wednesday, May 31, and then every Tuesday thereafter (June 6, 13, 20, and so on) until the release succeeded. Sites should avoid scheduling production work during the release window.
BBN asked each site to flip switches on their machines and be ready to help. They would try again on May 31 and keep trying every Tuesday until it worked.
§3Status Today
This RFC was replaced by RFC 359. It documents a critical early challenge in managing the growing ARPANET: coordinating system changes across many independent operators.
This note got replaced by a later one, but it shows that even in 1972, changing software across a whole network was hard.