IMP System change notification
A notice explaining why the May 1972 IMP software release failed
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 ]
ISO Plain Language
On this page
§1Why the Release Failed
BBN's attempt to release IMPSYS 2600 on May 15 was unsuccessful. The RFC says the causes were operational rather than programming bugs.
The network had grown too large for BBN to coordinate operator intervention at every site. In addition, IMPs running the new system were affected by adjacent IMPs running the old system, and the reverse also occurred. BBN called this the poisoning effect.
The upgrade failed for two operational reasons: BBN could not coordinate every site easily, and neighboring machines running different versions interfered with one another.
§2Preparation for Another Attempt
BBN asked sites with Model 516 IMPs to keep four named switches in specified positions. It also asked sites not to use the IMP Trace routine during release days. Terminal IMPs could be turned off for significant parts of those days.
The next attempt was scheduled for Wednesday, May 31, followed by attempts every Tuesday until the release succeeded. BBN expected to begin early in the day, approximately 7 a.m. Eastern Daylight Time, and suggested that sites avoid scheduling production work over the network during an attempt.
BBN gave sites switch settings and asked them to avoid certain activities during the upgrade. It planned to retry on May 31 and each Tuesday after that until the release worked.
§3Purpose of the Notice
This RFC asks network sites to cooperate with the planned release and explains why the previous attempt took longer than expected. BBN said operator coverage was not required for the planned process, but hoped it would be available if unexpected problems arose.
The unit metadata records RFC 359 as the successor to this notification.
The notice tells operators what BBN learned and what it asked them to do next. RFC 359 later replaced it.