Please delete me from your mailing list - Thank you

Please delete me from your mailing list - Thank you

[vijay]

----------
> From: Automatic digest processor <LISTSERV@LISTSERV.NODAK.EDU>
> To: Recipients of INFO-ADA digests <INFO-ADA@LISTSERV.NODAK.EDU>
> Subject: INFO-ADA Digest - 24 Aug 1997 to 25 Aug 1997
> Date: Tue, 26 Aug 1997 00:07:07 -0500
>
>There are 4 messages totalling 345 lines in this issue.
>
>Topics of the day:
>
>  1. Critique of Ariane 5 paper (finally!) (2)
>  2. AZ - SOFTWARE ENGINEERS with ADA experience (CONTRACTS NOW!)
>  3. PLEASE REMOVE ME FROM YOUR MAILING LIST - Thank You
>
>----------------------------------------------------------------------
>
>Date:    Mon, 25 Aug 1997 07:15:04 GMT
>From:    Don Harrison <donh@SYD.CSA.COM.AU>
>Subject: Re: Critique of Ariane 5 paper (finally!)
>
>Robert S. White wrote:
>
>:  Ken, myself, and a few others have been arguing that you can
>:not always employ the executable code aspects of DBC (or Ada
>:run time checks) in hard real time systems with constrained
>:resources.
>
>Agree - for current technology which requires *sequential* evaluation of
>assertions.
>
>[..]
>
>:.. But I think it is a "good thing" to use assertions and/or a DBC
>:methodology whenever practical.  Unfortunately, IME, it is
>:often not practical for resource constrained hard real time
>:systems.
>
>Agree.
>
>
>Don.
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Don Harrison     nospam@thankyou.maam.com.au
>
>------------------------------
>
>Date:    Mon, 25 Aug 1997 18:15:58 +1000
>From:    Thomas Beale <thomas_beale@INVEST.AMP.COM.AU>
>Subject: Re: Critique of Ariane 5 paper (finally!)
>
>Ken Garlington wrote:
>>
>I've been caught out using a very informal argument and relying
>on "commonly agreed" norms of software engineering. But as you
>imply, (and I have done often enough, many of these can be
>wrong). So...
>
>> > Jeff Kotula wrote:
>> > > 1. Any evaluation of a system's reliability must be based on its
>> > > requirements specification.
>>
>> False. The Musa model, for example, does not require examination
>> of a requirements specification.
>
>I don't know what the Musa model is; does its definition of reliability
>of a system rely in no way on the requirements (or any transformation of
>any expression of it)? If not, does its idea of reliability not relate
>to any expression of the correctness of the system (of which the
>requirements spec is an instance)?
>
>> > > 2. Any evaluation of a system's reliability will directly correlate with
>> > > the reliability of its component's reliability.
>>
>> For software, not true. See "Safeware." The sum of the component
>> reliability
>> does not necessarily equal the system's reliability. (This is a common
>> mistake made when attempting to apply hardware reliability models to
>> software.)
>
>I would have to agree here. A better statement would have been:
>"A system's unreliability will strongly correlate to the unreliability
>of the components". I.e., you can build rubbish out of good bits, but
>its unlikely (if not impossible) to build a good system out of
>broken components.
>
>> > > 3. Any evalution of a component's reliability must be based on its
>> > > requirements specification.
>>
>> Again, not true. See above.
>
>I would need to be convinced by this "Musa" argument...
>
>> > which closes the loop from requirements to implementation. I think
>> > this argument is a pretty fair statement of why DBC is not just another
>> > tool in the toolkit: (to paraphrase the above) DBC is a way of
>> > formalising, implementing, and enforcing the requirements specification
>> > at the design and implementation levels of abstraction.
>>
>> Unfortunately, there can be elements of the requirements specification
>> which cannot be enforced at the implementation level (e.g. certain
>> classes of assumptions about the external environment).
>
>Naturally... probably the majority (measured by pages of document or
>whatever) is informal or semi-formal, and does not map directly to
>the various levels of design/implementation. But on the other hand,
>if contracts were used as a formalism in the reqts spec, then the
>ability to map through would be better.
>
>> > Where I think there is more room for debate is in how DBC should be
>> > implemented. I have used Eiffel's DBC for some time, and it is miles
>> > ahead of no DBC.
>>
>> What did you use before DBC?
>
>At university (Qld, Australia), we used formal assertions (a la
>Dijkstra) to specify the meaning of program components. There
>were no tools to support this, but we could easily code up test
>cases to test correctness by encoding these statements (in
>"pascal plus").
>
>I spent about 6 years in distributed real-time SCADA systems
>coded in K&R C, and at the end, had come to the conclusion (along
>with other team members and developers) that modules built using
>PRE_CONDITION, POST_CONDITION, and CHECK (macro) statements
>in the code were better because:
>
>a) they were more readable & thus maintainable;
>
>b) they produced much more useful man pages (we built automated
>   back-extraction tools) - developers could avoid defensive
>   programming & complain to the authors if their program
>   died in a way forbidden by the assertion statements;
>
>c) they were _much_ easier to debug (we used the Fred Fish dbug
>   macros as well, and integrated them with the assertions);
>
>d) they acted as a repository for design-level decisions, which
>   began to replace voluminous design documentation which was
>   immediately out of date;
>
>e) the incentive was there to write more generic, re-usable
>   modules, since for the first time, client developers had
>   a trustworthy way of knowing what a given module did,
>   without having to look at the code: the (automatically
>   extracted) man page with both function signatures (like
>   you get if you do "man strcat" for example, on a unix
>   system), and the pre- and post-condition statements....
>   this was treated as the "truth". A new experience -
>   trust in software not written by me - was discovered.
>
>Although we never had the means or time to make comparative
>studies of code done this way versus the old way, I  believe
>we were able to write much better software, more quickly, and
>that it was more reliable because a) our ability to test it
>was much better, and b) it tended to get re-used more often
>(and hence further tested).
>
>I should mention that we weren't doing this for amusement
>either: these systems control e.g. gas pipelines, electric
>power transmission and distribution systems (e.g. Sydney...),
>and passenger rail systems. Reliability was the most
>important thing in the world.
>
>As well as the eariler Dijkstra/Hoare etc work, Meyer's
>original OOSC was a major influence on this work, since it
>encouraged us to think it would be possible to do this
>kind of thing in actual software (not hidden away in
>some document), and it showed us what reasonable syntax
>might look like for object-oriented software.
>
>Since then I have felt that formalisms that don't support
>these ideas are way behind those that do. Eiffel is the
>only out-of-the-box formalism in this category that is
>available for building object-oriented software, but other
>formalisms (even the augmented C "formalism" I describe
>above) have great merit. It just depends on how much pain
>you want to go through to make reliable software.
>
>I have since used Eiffel for some years because
>- I am allergic to pain,
>- it does the rest of the OO paradigm so well.
>
>- thomas beale
>
>------------------------------
>
>Date:    Sun, 24 Aug 1997 07:51:18 -0600
>From:    Resumes@ICCJOBS.COM
>Subject: AZ - SOFTWARE ENGINEERS with ADA experience (CONTRACTS NOW!)
>
> ICC INTERNATIONAL COMPUTER CONSULTANTS, Inc. located in Scottsdale,
>Arizona has CONTRACT OPENINGS in the Phoenix area for candidates with the
> following backgrounds:
>
>  1.  Must have a BSCS, BSAE, or BSEE and 3+ years of S/W
>       Development experience.
>
>  2.  Solid C or Ada programming skills.  Vax literate,  Knowledge of
>       Software Configuration Management principles a plus.
>
>
>
>    Please fax your resume to ICC:    Resumes@iccjobs.com
>                                                                       or
>                                                          (602) 585-5449
>
>    ICC International Computer Consultants, Inc.
>    Scottsdale, Arizona
>    (602) 585-5488
>
>
>-------------------==== Posted via Deja News ====-----------------------
>      http://www.dejanews.com/     Search, Read, Post to Usenet
>
>------------------------------
>
>Date:    Mon, 25 Aug 1997 18:23:24 -0700
>From:    vijay <vijay@QNET.COM>
>Subject: PLEASE REMOVE ME FROM YOUR MAILING LIST - Thank You
>
>----------
>> From: Automatic digest processor <LISTSERV@LISTSERV.NODAK.EDU>
>> To: Recipients of INFO-ADA digests <INFO-ADA@LISTSERV.NODAK.EDU>
>> Subject: INFO-ADA Digest - 23 Aug 1997 to 24 Aug 1997
>> Date: Mon, 25 Aug 1997 00:03:07 -0500
>>
>>There are 3 messages totalling 119 lines in this issue.
>>
>>Topics of the day:
>>
>>  1. Library model in Ada. was Re: Difference between ADA and c++
>>  2. Critique of Ariane 5 paper (finally!)
>>  3. Difference between ADA and c++
>>
>>----------------------------------------------------------------------
>>
>>Date:    Sat, 23 Aug 1997 17:12:44 -0700
>>From:    Undetermined origin c/o LISTSERV administrator
>>         <owner-LISTSERV@LISTSERV.NODAK.EDU>
>>Subject: Library model in Ada. was Re: Difference between ADA and c++
>>
>>In article <01bcafdf$50784b80$7774d8cc@fatman>, "Michael says...
>>>
>>>Here are several comparisions of Ada and C++ on the www:
>>>
>>>Langauge comparisons:
>>>
>>>A Comparison of Ada, C, and C++
>>>http://rep1.iei.pi.cnr.it/projects/JADA/ada-collection/tuft.html
>>>
>>
>>thanks for the pointers! I did not have some of these before.
>>
>>Now, I was reading this below, from the above paper:
>>
>>"1) Separate Compilation and Library Management
>>
>>   Ada: An Ada compiler is required to enforce consistency and
>>strong type checking across separate compilation.  The concept of
>>                                                   ^^^^^^^^^^^^^^
>>a program library is built into the language, based on separately
>>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>compilable modules called "library units" whose names are part of
>>a hierarchical name space."
>>
>>GNAT, probably the most popular Ada95 compiler, does NOT use the
>>program library model, but uses the code-source model, i.e. the
>>traditional model.
>>
>>So, what going on here? who is wrong, and who is right?
>>
>>thanks,
>>Nasser
>>
>>------------------------------
>>
>>Date:    Sat, 23 Aug 1997 22:09:00 -0500
>>From:    Ken Garlington <kennieg@FLASH.NET>
>>Subject: Re: Critique of Ariane 5 paper (finally!)
>>
>>Robert S. White wrote:
>>>
>>> The Ariane 4 IRS software as-is reuse should not have made it
>>> by such reviews.  Please read Ken's rebuttal paper:
>>>
>>>   http://www.progsoc.uts.edu.au/~geldridg/eiffel/ariane/
>>>
>>>   My reading of it does not indicate a general "critising DBC"
>>> but rather it summerizes:
>>>
>>>   "In the specific case of the Ariane IRS design fault, there
>>>   is not clear and compelling evidence that DBC/Eiffel
>>>   assertions were likely to have uncovered the fault prior to
>>>   operational use, either through their documentation, test,
>>>   or execution value. Furthermore, alternative means were
>>>   available to the Ariane team to isolate the particular
>>>   fault, even without the use of DBC/Eiffel. Therefore,
>>>   although there may be a compelling claim to use DBC/Eiffel
>>>   in real-time safety-critical systems, the Ariane case
>>>   (and the Eiffel paper describing this case) does not
>>>   support such a claim."
>>
>>In addition, it states in section 6:
>>
>>"It would not be appropriate to use the criticisms here to say
>>in the general case that assertions have no value, anywhere
>>("casuistry"), but this criticism does not attempt to do this.
>>It focuses on the specific claim in the Eiffel paper in the
>>context of the Ariane IRS fault....
>>
>>"Several Eiffel advocates will attest that they like the use of
>>Eiffel for their domain. Eiffel may be very useful in some domains,
>>however Ariane is a real-time embedded safety-critical system and
>>has unique properties (as described above). Again, this is a specific,
>>not a general, criticism of DBC/Eiffel."
>>
>>Perhaps my paper is so boring that no one made it to this
>>section :)
>>
>>------------------------------
>>
>>Date:    Sun, 24 Aug 1997 08:07:32 GMT
>>From:    Dale Stanbrough <dale@GOANNA.CS.RMIT.EDU.AU>
>>Subject: Re: Difference between ADA and c++
>>
>>"   Ada: An Ada compiler is required to enforce consistency and
>> strong type checking across separate compilation.  The concept of
>>                                                    ^^^^^^^^^^^^^^
>> a program library is built into the language, based on separately
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> compilable modules called "library units" whose names are part of
>> a hierarchical name space."
>>
>> GNAT, probably the most popular Ada95 compiler, does NOT use the
>> program library model, but uses the code-source model, i.e. the
>> traditional model."
>>
>>Gnat does have a program library, just as Intermetrics also has
>>a program library. The library just happens to be implemented as
>>a series of source code files, and not some mysterious black box
>>piece of software.
>>
>>List through the requirements of such a library, and you'll find
>>that the source code model can meet them.
>>
>>Dale
>>
>>------------------------------
>>
>>End of INFO-ADA Digest - 23 Aug 1997 to 24 Aug 1997
>>***************************************************
>>
>
>------------------------------
>
>End of INFO-ADA Digest - 24 Aug 1997 to 25 Aug 1997
>***************************************************
>

Re: Please delete me from your mailing list - Thank you

[Unknown]

When you subscribed to this mailing list, you received a message asking you to 
keep it for further reference about the list. The message has a subject of 
"You are now subscribed to the INFO-ADA list", in this file are details of how 
to manipulate your membership including how to remove yourself from the list.

I will paste the entire contents of this file below. (Did you delete it ? :-))

Your subscription  to the  INFO-ADA list  (Ada programming  language) has
been accepted.

Please save this message for future  reference, especially if this is the
first time you subscribe to an  electronic mailing list. If you ever need
to  leave the  list,  you  will find  the  necessary instructions  below.
Perhaps  more importantly,  saving a  copy of  this message  (and of  all
future subscription notices  from other mailing lists) in  a special mail
folder will give you instant access to the list of mailing lists that you
are subscribed  to. This may  prove very useful the  next time you  go on
vacation and  need to leave  the lists temporarily so  as not to  fill up
your  mailbox while  you  are away!  You should  also  save the  "welcome
messages" from the  list owners that you will  occasionally receive after
subscribing to a new list.

To send  a message to  all the people  currently subscribed to  the list,
just send  mail to  INFO-ADA@LISTSERV.NODAK.EDU. This is  called "sending
mail to the list", because you send mail to a single address and LISTSERV
makes  copies  for all  the  people  who  have subscribed.  This  address
(INFO-ADA@LISTSERV.NODAK.EDU) is also called the "list address". You must
never try to send any command to that address, as it would be distributed
to all the people  who have subscribed. All commands must  be sent to the
"LISTSERV address", LISTSERV@LISTSERV.NODAK.EDU. It  is very important to
understand  the difference  between the  two, but  fortunately it  is not
complicated. The LISTSERV address is like  a FAX number that connects you
to  a machine,  whereas the  list  address is  like a  normal voice  line
connecting you to a person. If you make a mistake and dial the FAX number
when you wanted to talk to someone on the phone, you will quickly realize
that you  used the wrong  number and call again.  No harm will  have been
done. If on the other hand  you accidentally make your FAX call someone's
voice  line,  the  person  receiving the  call  will  be  inconvenienced,
especially if your FAX then re-dials  every 5 minutes. The fact that most
people will eventually connect the FAX machine to the voice line to allow
the FAX  to go through  and make  the calls stop  does not mean  that you
should continue to send FAXes to  the voice number. People would just get
mad at you.  It works pretty much  the same way with  mailing lists, with
the difference  that you are calling  hundreds or thousands of  people at
the same  time, and consequently  you can expect a  lot of people  to get
upset if you consistently send commands to the list address.

You  may leave  the list  at  any time  by sending  a "SIGNOFF  INFO-ADA"
command to  LISTSERV@LISTSERV.NODAK.EDU. You  can also tell  LISTSERV how
you want it to  confirm the receipt of messages you send  to the list. If
you do  not trust  the system,  send a "SET  INFO-ADA REPRO"  command and
LISTSERV will send you  a copy of your own messages, so  that you can see
that the  message was  distributed and  did not get  damaged on  the way.
After a while  you may find that this is  getting annoying, especially if
your mail program does not tell you  that the message is from you when it
informs you that new  mail has arrived from INFO-ADA. If  you send a "SET
INFO-ADA  ACK   NOREPRO"  command,  LISTSERV   will  mail  you   a  short
acknowledgement  instead,  which  will  look different  in  your  mailbox
directory. With most mail programs you will know immediately that this is
an  acknowledgement  you  can  read  later. Finally,  you  can  turn  off
acknowledgements completely with "SET INFO-ADA NOACK NOREPRO".

Following  instructions from  the list  owner, your  subscription options
have been  set to  "DIGESTS REPRO  MIME" rather  than the  usual LISTSERV
defaults. For more information about  subscription options, send a "QUERY
INFO-ADA" command to LISTSERV@LISTSERV.NODAK.EDU.

Contributions sent to this list are automatically archived. You can get a
list  of the  available  archive  files by  sending  an "INDEX  INFO-ADA"
command to  LISTSERV@LISTSERV.NODAK.EDU. You  can then order  these files
with  a "GET  INFO-ADA  LOGxxxx" command,  or  using LISTSERV's  database
search facilities. Send  an "INFO DATABASE" command  for more information
on the latter.

This  list is  available  in digest  form.  If you  wish  to receive  the
digested  version of  the  postings,  just issue  a  SET INFO-ADA  DIGEST
command.

Please note that  it is presently possible for other  people to determine
that  you are  signed up  to the  list through  the use  of the  "REVIEW"
command,  which  returns   the  e-mail  address  and  name   of  all  the
subscribers. If  you do not  want your name to  be visible, just  issue a
"SET INFO-ADA CONCEAL" command.

More  information on  LISTSERV  commands  can be  found  in the  LISTSERV
reference  card, which  you can  retrieve  by sending  an "INFO  REFCARD"
command to LISTSERV@LISTSERV.NODAK.EDU.