RFC 343 UNKNOWN IMP · OPERATIONS

IMP System change notification

News about a failed software upgrade and the plan to try again.

On rfc-editor.org ↗
PUBLISHED
May 1972
AUTHORS
A.M. McKenzie
STREAM
Legacy
BUILDS ON
RFC 331 — IMP System Change Notification
OBSOLETED BY
RFC 359 — Status of the Release of the New IMP System (2600)
FAILED RELEASE DATE
May 15, 1972
SCHEDULED RETRY START
May 31, 1972
RETRY FREQUENCY
Every Tuesday
DOI
10.17487/RFC0343

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
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
PROBLEMBBN tried to upgrade the IMPSYS software on all network IMPs simultaneously on May 15, 1972, but the upgrade failed because the network had grown too large to coordinate.
MECHANISMThe failure happened because old and new systems running side by side interfered with each other, and coordinating operator actions across all sites proved impossible. BBN scheduled new attempts for later dates.
WHY IT MATTERSThis early incident showed the challenges of managing distributed systems and coordinating changes across many independent sites.

§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.

§4References