RFC 343 UNKNOWN IMP · OPERATIONS

IMP System change notification

A notice explaining why the May 1972 IMP software release failed

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)
FIRST FAILED ATTEMPT
May 15
NEXT SCHEDULED ATTEMPT
Wednesday, May 31
APPROXIMATE START TIME
7 a.m. EDT
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  ]

ISO Plain Language

On this page
PROBLEMThe attempted release of IMPSYS 2600 on May 15 did not succeed.
MECHANISMBBN attributed the failure to difficulty coordinating operators across the larger network and to interference between adjacent IMPs running different systems.
NEXT STEPSThe notice scheduled another attempt for May 31 and then each Tuesday until success; RFC 359 later replaced it.

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

§4References