From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,885dab3998d28a4
X-Google-Attributes: gid103376,public
From: "Marin David Condic, 407.796.8997, M/S 731-93" <condicma@PWFL.COM>
Subject: Re: Ariane 5 failure
Date: 1996/10/03
Message-ID: <96100316350404@psavax.pwfl.com>#1/1
X-Deja-AN: 187012423
sender: Ada programming language <INFO-ADA@LISTSERV.NODAK.EDU>
comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
x-vms-to: SMTP%"INFO-ADA@VM1.NODAK.EDU"
newsgroups: comp.lang.ada
x-vms-cc: CONDIC
Date: 1996-10-03T00:00:00+00:00
List-Id: <comp.lang.ada>


Ken Garlington <garlingtonke@LMTAS.LMCO.COM> writes:
>Wayne L. Beavers wrote:
>>
>> I have been reading this thread awhile and one topic that I have not seen
>mentioned is protecting the code
>> area from damage.  When I code in PL/I or any other reentrant language I
>always make sure that the executable
>> code is executing from read-only storage.  There is no way to put the data
>areas in read-only storage
>> (obviously) but I can't think of any reason to put the executable code in
>writeable storage.
>
>That's actually a pretty common rule of thumb for safety-critical systems.
>Unfortunately, read-only memory isn't exactly read-only. For example, hardware
>errors
>can cause a random change in the memory. So, it's not a perfect fix.
>
    Actually there is a reason for sucking the code out of EEPROM and
    into RAM. EEPROMs (as I understand what the hardware dweebes tell
    me) are unusually susceptible to single event upsets (SEUs) if you
    have lots of gamma radiation hanging around in the neighborhood.
    Whereas RAMs are easier to make Rad-Hard and survive this stuff
    better.

    This poses problems for us software geeks to solve when creating
    the bootstrap, but there are apparently good engineering reasons
    for doing so. It would be nice if we could simply put an S.E.P.
    Field (S.omebody E.lses P.roblem) around the hardware issues, but
    once in a while the software guys have to bail out the hardware
    guys because of physics.

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    Glendower: "I can call spirits from the vasty deep."
    Hotspur: "Why so can I, or so can any man; but will they come when
    you do call for them?"

        -- Shakespeare, "Henry IV"
===============================================================================