Subject: RISKS DIGEST 11.15
REPLY-TO: risks@csl.sri.com

RISKS-LIST: RISKS-FORUM Digest  Thursday 21 February 1991  Volume 11 : Issue 15

        FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS 
   ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

  Contents:
Racetrack overpayments (Rodney Hoffman)
Peace Shield in trouble (Henry Spencer)
Is Unix the ultimate computer virus? (Mike T. on Dick Gabriel, via Martin Minow)
Re: Murder, She Wrote (Jerry Hollombe)
Re: Maintenance, Warranties, etc. (Charles Shub, Joseph M. Newcomer,
    Richard H. Miller, John Sullivan, Greg Johnson, Gene Spafford)

 The RISKS Forum is moderated.  Contributions should be relevant, sound, in 
 good taste, objective, coherent, concise, and nonrepetitious.  Diversity is
 welcome.  CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive 
 "Subject:" line.  Others ignored!  REQUESTS to RISKS-Request@CSL.SRI.COM.
 FTP VOL i ISSUE j: ftp CRVAX.sri.com<CR>login anonymous<CR>AnyNonNullPW<CR>
 CD RISKS:<CR>GET RISKS-i.j<CR> (where i=1 to 11, j is always TWO digits. Vol i
 summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye" logs out.
 ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
 Relevant contributions may appear in the RISKS section of regular issues
 of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.

----------------------------------------------------------------------

Date: 	Wed, 20 Feb 1991 15:16:26 PST
From: Rodney Hoffman <Hoffman.El_Segundo@Xerox.com>
Subject: Racetrack overpayments

A short item by Steve Schuelein in the 'Los Angeles Times' 18 Feb. 91 says that
"a series of computer malfunctions" resulted in $26,000 in excess payouts at
the local Los Alamitos racetrack.  A too-lucrative payoff was posted for
several minutes before the error was corrected.

Track president and general manager Lloyd Arnold said the computer problems
also prevented satellite wagering at 14 outlets in Nevada, and the Nevada
Racing Commission might suspend wagering on races at Los Alamitos until the
problems are corrected.  According to Arnold, "[Amtote] said a printer on the
computer malfunctioned, but I think the personnel here is not qualified."

------------------------------

Date: Wed, 20 Feb 91 22:21:48 EST
From: henry@zoo.toronto.edu
Subject: Peace Shield in trouble

No, this is not another SDI contribution!  "Peace Shield" is the USAF-
managed project to provide Saudi Arabia with an integrated air-defence
control system.  From Flight International, 23 Jan:

	The USAF is looking to Hughes, Unisys, Westinghouse or General
	Electric to pick up the pieces of the Peace Shield Saudi Arabian
	air-defence ground environment following termination of most of
	Boeing's contracts on the beleaguered programme.

	The USAF says it cut the bulk of the $1.05 billion contract
	because of Boeing's "...failure to make progress so as to
	endanger final operational capability". [sic]

	[Original target date was April 1991.  Revised Boeing estimate
	was August 1994; USAF hopes others can do better.  USAF action
	probably prompted by Saudi pressure.]

	Boeing's difficulties centred on developing the software for
	integrating the disparate sensors, sector operations, sector
	command and command operations centres.

	The programme appears to have suffered a similar fate to other
	software-intensive projects in that the prime contractor
	underestimated the quantity and the technical complexity of
	the software.  Peace Shield required hundreds of thousands of
	code lines to be developed.

	The depth of the problem encountered by the company was indicated
	by its failure to meet even a considerably revised continental
	United States integration testing. [sic]

	[Boeing retains some minor hardware contracts for Peace Shield.]

------------------------------

Date: Wed, 20 Feb 91 13:12:19 PST
From: "Martin Minow, ML3-5/U26  19-Feb-1991 1606" <minow@bolt.enet.dec.com>
Subject: Is Unix the ultimate computer virus
                                            [Slightly edited by Martin Minow]

From:	"mt@media-lab.media.mit.edu"
To:	unix-haters@mc.lcs.mit.edu
Subj:	Worse is better 

I apologize for the relative lack of vituperation in the following,
but you can draw your own conclusions.
 
MADRE::MWM                                          203 lines   8-FEB-1991 
15:14

>> I once went to hear a talk by Thompson at MIT.  Thompson said one of
>> the professors had said to him, "I hate you.  UNIX stopped all research
>> in operating systems."  Thompson apologized.
 
The professor exaggerates - but not by much. The comments by Bob in .29
are relevant in both cases. Oddly enough, there's been some talk in
comp.society.futures about windowing systems, and an interesting article
(included below) on OS developement (included below) landed in my
mailbox recently.
 
The problem with OSF/Motif - and X in general - is not that it's missing
features; it's that critical parts of it are arcane and unusable. I'm not sure
that the resource mechanism can be deleted from it in any reasonable way.
 
	<mike
 
This is an excerpt from Dick Gabriel's paper, "Good News, Bad News, and
How to Win Big."  The "MIT guy" and "Berkeley guy" mentioned herein are
Dan Weinreb and Bill Joy.
 
- - ---------- cut here and glue this to the inside of your forehead ----------
 
2.1    THE RISE OF ``WORSE IS BETTER''
 
I and just about every designer of Common Lisp and CLOS has had extreme
exposure to the MIT/Stanford style of design. The essence of this style can be
captured by the phrase ``the right thing.'' To such a designer it is important
to get all of the following characteristics right:
 
  + Simplicity -- the design must be simple, both in implementation and
    interface. It is more important for the interface to be simple than the
    implementation.
 
  + Correctness -- the design must be correct in all observable aspects.
    Incorrectness is simply not allowed.
 
  + Consistency -- the design must not be inconsistent. A design is allowed to
    be slightly less simple and less complete to avoid inconsistency.
    Consistency is as important as correctness.
 
  + Completeness -- the design must cover as many important situations as is
    practical. All reasonably expected cases must be covered. Simplicity is
    not allowed to overly reduce completeness.
 
I believe most people would agree that these are good characteristics.  I will
call the use of this philosophy of design the ``MIT approach.''  Common Lisp
(with CLOS) and Scheme represent the MIT approach to design and
implementation.
 
The worse-is-better philosophy is only slightly different:
 
  + Simplicity -- the design must be simple, both in implementation and
    interface.  It is more important for the implementation to be simple than
    the interface. Simplicity is the most important consideration in a design.
 
  + Correctness -- the design must be correct in all observable aspects. It is
    slightly better to be simple than correct.
 
  + Consistency -- the design must not be overly inconsistent.  Consistency can
    be sacrificed for simplicity in some cases, but it is better to drop those
    parts of the design that deal with less common circumstances than to
    introduce either implementational complexity or inconsistency.
 
  + Completeness -- the design must cover as many important situations as is
    practical. All reasonably expected cases should be covered.  Completeness
    can be sacrificed in favor of any other quality. In fact, completeness
    must sacrificed whenever implementation simplicity is jeopardized.
    Consistency can be sacrificed to achieve completeness if simplicity is
    retained; especially worthless is consistency of interface.
 
Early Unix and C are examples of the use of this school of design, and I will
call the use of this design strategy the ``New Jersey approach.'' I have
intentionally caricatured the worse-is-better philosophy to convince you that
it is obviously a bad philosophy and that the New Jersey approach is a bad
approach.
 
However, I believe that worse-is-better, even in its strawman form, has better
survival characteristics than the-right-thing, and that the New Jersey
approach when used for software is a better approach than the MIT approach.
 
Let me start out by retelling a story that shows that the MIT/New-Jersey
distinction is valid and that proponents of each philosophy actually believe
their philosophy is better.
 
Two famous people, one from MIT and another from Berkeley (but working on
Unix) once met to discuss operating system issues. The person from MIT was
knowledgeable about ITS (the MIT AI Lab operating system) and had been reading
the Unix sources. He was interested in how Unix solved the PC loser-ing
problem. The PC loser-ing problem occurs when a user program invokes a system
routine to perform a lengthy operation that might have significant state, such
as IO buffers. If an interrupt occurs during the operation, the state of the
user program must be saved. Because the invocation of the system routine is
usually a single instruction, the PC of the user program does not adequately
capture the state of the process. The system routine must either back out or
press forward. The right thing is to back out and restore the user program PC
to the instruction that invoked the system routine so that resumption of the
user program after the interrupt, for example, re-enters the system routine.
It is called ``PC loser-ing'' because the PC is being coerced into ``loser
mode,'' where ``loser'' is the affectionate name for ``user'' at MIT.
 
The MIT guy did not see any code that handled this case and asked the New
Jersey guy how the problem was handled. The New Jersey guy said that the Unix
folks were aware of the problem, but the solution was for the system routine
to always finish, but sometimes an error code would be returned that signaled
that the system routine had failed to complete its action. A correct user
program, then, had to check the error code to determine whether to simply try
the system routine again. The MIT guy did not like this solution because it
was not the right thing.
 
The New Jersey guy said that the Unix solution was right because the design
philosophy of Unix was simplicity and that the right thing was too complex.
Besides, programmers could easily insert this extra test and loop. The MIT guy
pointed out that the implementation was simple but the interface to the
functionality was complex. The New Jersey guy said that the right tradeoff has
been selected in Unix -- namely, implementation simplicity was more important
than interface simplicity.
 
The MIT guy then muttered that sometimes it takes a tough man to make a tender
chicken, but the New Jersey guy didn't understand (I'm not sure I do either).
 
Now I want to argue that worse-is-better is better. C is a programming
language designed for writing Unix, and it was designed using the New Jersey
approach. C is therefore a language for which it is easy to write a decent
compiler, and it requires the programmer to write text that is easy for the
compiler to interpret. Some have called C a fancy assembly language. Both
early Unix and C compilers had simple structures, are easy to port, require
few machine resources to run, and provide about 50%-80% of what you want from
an operating system and programming language.
 
Half the computers that exist at any point are worse than median (smaller or
slower). Unix and C work fine on them.  The worse-is-better philosophy means
that implementation simplicity has highest priority, which means Unix and C
are easy to port on such machines.  Therefore, one expects that if the 50%
functionality Unix and C support is satisfactory, they will start to appear
everywhere.  And they have, haven't they?
 
Unix and C are the ultimate computer viruses.
 
A further benefit of the worse-is-better philosophy is that the programmer is
conditioned to sacrifice some safety, convenience, and hassle to get good
performance and modest resource use. Programs written using the New Jersey
approach will work well both in small machines and large ones, and the code
will be portable because it is written on top of a virus.
 
It is important to remember that the initial virus has to be basically good.
If so, the viral spread is assured as long as it is portable.  Once the virus
has spread, there will be pressure to improve it, possibly by increasing its
functionality closer to 90%, but users have already been conditioned to accept
worse than the right thing.  Therefore, the worse-is-better software first
will gain acceptance, second will condition its users to expect less, and
third will be improved to a point that is almost the right thing.  In concrete
terms, even though Lisp compilers in 1987 were about as good as C compilers,
there are many more compiler experts who want to make C compilers better than
want to make Lisp compilers better.
 
The good news is that in 1995 we will have a good operating system and
programming language; the bad news is that they will be Unix and C++.
 
There is a final benefit to worse-is-better. Because a New Jersey language and
system are not really powerful enough to build complex monolithic software,
large systems must be designed to reuse components. Therefore, a tradition of
integration springs up.
 
How does the right thing stack up? There are two basic scenarios: the ``big
complex system scenario'' and the ``diamond-like jewel'' scenario.
 
The ``big complex system'' scenario goes like this:
 
First, the right thing needs to be designed. Then its implementation needs to
be designed. Finally it is implemented. Because it is the right thing, it has
nearly 100% of desired functionality, and implementation simplicity was never
a concern so it takes a long time to implement. It is large and complex.  It
requires complex tools to use properly. The last 20% takes 80% of the
effort, and so the right thing takes a long time to get out, and it only runs
satisfactorily on the most sophisticated hardware.
 
The ``diamond-like jewel'' scenario goes like this:
 
The right thing takes forever to design, but it is quite small at
every point along the way. To implement it to run fast is either
impossible or beyond the capabilities of most implementors.
 
The two scenarios correspond to Common Lisp and Scheme.
 
The first scenario is also the scenario for classic artificial intelligence
software.
 
The right thing is frequently a monolithic piece of software, but for no
reason other than that the right thing is often designed monolithically.
That is, this characteristic is a happenstance.
 
The lesson to be learned from this is that it is often undesirable to go for
the right thing first. It is better to get half of the right thing available
so that it spreads like a virus. Once people are hooked on it, take the time
to improve it to 90% of the right thing.
 
A wrong lesson is to take the parable literally and to conclude that C is the
right vehicle for AI software. The 50% solution has to be basically right, and
in this case it isn't.
 
But, one can conclude only that the Lisp community needs to seriously rethink
its position on Lisp design.  I will say more about this later.
 
 --- end ---

------------------------------

Date: 21 Feb 91 02:01:58 GMT
From: hollombe@ttidca.tti.com (The Polymath)
Subject: Re: Murder, She Wrote (RISKS-11.13)

}It seems to me like a little well-placed pressure on TV writers and producers
}might not only get them back in line ...

Alas, they never were in line in the first place.  I'm the son of a lawyer and
have many friends in the legal professions.  All agree on one thing:
Practically everything you see pertaining to the U.S. legal system in
television dramas is _wrong_.  Always has been.  Don't expect them to clean up
their act any time soon.

Jerry Hollombe, Citicorp, 3100 Ocean Park Blvd., Santa Monica, CA 90405
{rutgers|pyramid|philabs|psivax}!ttidca!hollombe (213) 450-9111, x2483

------------------------------

Date: Wed, 20 Feb 91 16:16:34 -0700
From: Charles Shub <cdash@mumm.Colorado.EDU>
Subject: Re: Maintenance  (car recall/software analogies, RISKS-11.14)

=>  [ several articles on who gets fixes to bugs in software ]

I find this thread of discussion interesting and amusing.

We don't really do any "software maintenance" in this field.  What we are
really doing is "software upgrades" no matter what we want to call it.  I don't
know the history behind the term "maintenance" in this context but can
hypothesize several reasons.

The discussion brought to mind some past frustrations in dealing with a
subsidiary of Ford Motor Company, the frustrations arising on my part because
of my inability to convince some people there that software was somehow
fundamentally different from automobiles, and hence the construction processes
were probably dissimilar.  My frustration reached its peak when I was unable to
properly convey my incredulity at the notion of periodic scheduled preventive
maintenance on a piece of software.  I still do not understand what that means.

The risk, of course, is that by using a "wrong" term we imply wrong things as
aptly demonstrated (albeit peripherally) in the recent discussion of bug fixes.

charlie shub  cdash@boulder.Colorado.EDU  -or-  ..!{ucar|nbires}!boulder!cdash
              cdash@colospgs (BITNET)     -or-  (719) 593-3492

------------------------------

Date: Wed, 20 Feb 1991 18:18:37 -0500 (EST)
From: "Joseph M. Newcomer" <jn11+@andrew.cmu.edu>
Subject: Warranties

>>From: rick@pavlov.ssctr.bcm.tmc.edu (Richard H. Miller)
>>[As an aside, I have a difficult time understanding why a person who does not
>>pay for software maintenance expects to have bugs fixed. If you choose to
>>not pay for the service, then don't expect the vendor to fix it for free.] 

> brian@ucsd.Edu (Brian Kantor)
>When I pay for software, I do so
>under the assumption that it would perform as specified, not that it sorta
>might work kinda like what the manual said.

Absolutely.  In fact, if Brian hadn't written this, I would have.  If a
shrink-wrap software license was applied to any product other than software,
Ralph Nader or his equivalent would be on the industry in nanoseconds, and
rightfully so.  I am a former product developer.  We took the attitude that you
had to add new features to a product, enough to justify the upgrade fee, AND
fix all the bugs reported in the previous version, insofar as possible (note
that it was not a bug if the software didn't do something the user expected, as
long as it hadn't been promised).  I find it immoral and unethical to charge
for bug fixes; the product was defective.  But since we couldn't afford to give
out free updates, we simply made the user buy the bug fixes by buying the new
features.  This is not totally acceptable, but is the best a 2.5 person company
can do.  On the other hand, I find it totally unacceptable that a company like
Apollo could release a Pascal compiler with known code generation problems and
refuse to fix it for a year because "it wasn't in the release cycle".  The
compiler generated incorrect code for compile-time constant expressions.

If we don't police ourselves, some vastly less competent and authoritarian
group will eventually do it for us.  And as software gets out more into the
public there is less and less tolerance for the past attitudes.

Law is a way of formalizing what should be polite behavior.  If everyone were
polite, laws wouldn't be needed.

Business-as-usual is putting us all at RISK.

------------------------------

Date: 21 Feb 91 00:26:50 GMT
From: rick@pavlov.ssctr.bcm.tmc.edu (Richard H. Miller)
Subject: Re: Serious bug... (Pellett, RISKS-11.14)

Well, of all the postings so far in response to my original aside, this seems
to be the only one which read the rest of the article. I specifically made a 
point of asking whether this type of software defect warranted special 
treatment from software vendors. 

It is my feeling that there are two catagories of software defects that could
fit under this catagory, security defects and data corruption defects.I 
consider these two catagories to be similar to the type of defect which would
require a car to be recalled. They can cause the system to be destroyed or
data within it to become unreliable. [In a software sense this is comperable
to having the brakes fail or the gas tank explode.] These defects should be
fixed free of charge. 

Other types of defects would fit into the same category as what you get with a
car. The software is warrented for a period of time in which fixes will be
provided. At the end of this time, if you choose to not pay for maintenance,
then you are out of luck. [Just as if your distributor goes out on your card
after 1 year].

With this premise, what are the responsibilities of the vendor in providing
fixes to the two types of defects? I can see no problem on the part of S/W
vendors if a patch is all that is required to fix a problem. But if the problem
is in the design of the software and requires a redesign which would appear in
the next release, should users be provided the new version for free.

For the record, I believe that for security and data-integrity problems, the
vendor does have an obligation to provide fixes within the scope of the
original purchase.

Richard H. Miller, Asst. Dir. for Technical Support, Baylor College of
Medicine, One Baylor Plaza, 302H, Houston, Texas 77030   (713)798-3532

------------------------------

Date: Wed, 20 Feb 91 20:21:30 CST
From: sullivan@poincare.geom.umn.edu
Subject: Re: software warranties

Risks 11.14 had a very interesting discussion on software warranties.  Many
people responded to Richard Miller's suggestion (that someone who does not pay
for maintenance should not expect bug fixes) by pointing out that bugs are
defects and thus covered under the standard implicity warranties.

Flint Pellett suggests that software come with a limited-time guarantee, but
->if you are past the 90 days (or however long) and you didn't
->buy a maintenance contract, then you are (and ought to be) just as much out of
->luck as if you didn't buy a maintenance contract on your fridge.  Software
->buyers are likely to start paying attention to how long the guarantee is for,
->and not buy from companies with really short guarantee periods.

Since software does not deteriorate over time like hardware, I see little
point in putting a time limitation on any warranty.  Vendors may wish
to allow a short time period in which a dissatisfied customer could get
a refund, but bugs (no matter when they are discovered) were presumably
present at the time of purchase and should still be covered.  Of course,
there might be a problem if the company has long since discarded the
product.  But software usually has a limited useful life so I don't really
think we have to worry about people making warranty claims 20 years later.

There needs to be some limit, however, on the kinds of bugs covered.
Brian Kantor says
->I would maintain that a piece of software which is
->found, at any time, to not perform as specified at time of purchase is
->defective and must be remedied by the vendor.
I think this would merely lead to a lack of detailed specifications:
"You found a bug?  Oh, no, that's a feature."

It seems clear that safety-related bugs, like holes in operating systems,
should be fixed for free.  And if there is gross misrepresentation of
what the software does, or if it is so flaky as to be unusable, you would
want a refund.  If you buy a "screen editor" and get "ed", you return it.
But if you get "vi", I'm afraid you're stuck with a few minor problems
and shouldn't expect to have them fixed.  Everyone seems to know bugs
in "vi" (especially in autowrap), but don't hold your breath waiting for
Sun or Silicon Graphics or anyone like that to fix them.  The bugs are
often annoying, but "vi" is still quite useful, and does its basic job.
But does it "perform as specified"?

Software vendors should be expected to fix major bugs for free, but
when it comes to more obscure problems or those with easy workarounds,
this is less clear.  If the vendor has switched to a new version, with
substantial improvements along with fixes, it is hard for them to keep
maintaining all earlier versions.  While we might want free upgrades for
life, this should be an option at purchase time, not required by the
government, as it might drastically increase the cost of some software.

John Sullivan     sullivan@geom.umn.edu

------------------------------

Date: Thu, 21 Feb 91 00:37:30 EST
From: johnson@castor.cs.uga.edu (Greg Johnson)
Subject: Software is not Hardware...(AT&T != Ford)

Flint Pellet says:

>I would say that there is no reason software should be any different than      
>anything else you buy.  If you buy a new appliance, you get a guarantee for 90 
>days against defects in materials and workmanship, and when you buy software   
>you ought to get a similar guarantee.  A bug like this is a defect in the      
>workmanship, and if you are still covered by the guarantee, you ought to get it
>fixed free.  But if you are past the 90 days (or however long) and you didn't  
>buy a maintenance contract, then you are (and ought to be) just as much out of 
>luck as if you didn't buy a maintenance contract on your fridge.

I disagree.  The salient difference is that software, unlike hardware, is
not affected by physical laws.  Software is the expression of thought,
and does not wear out.  There are no bearings to go, no heat to fatigue.  Thus,
the defects which manifest themselves are purely a result of a failure on the
part of the manufacturer.   There is not, and should not be a MTBF for soft-
ware. Though migration between architectures may be grounds to void this
warranty, I cannot see how software houses can rationally set a warranty
period shorter than that on my hard drive.

------------------------------

Date: 21 Feb 91 17:02:00 GMT
From: spaf@cs.purdue.edu (Gene Spafford)
Subject: Re: warranties etc. (RISKS-11.14)

In RISKS 11.14 there were many responses along the lines of "If I pay
good money to buy software, I expect it to work as it should."

Brace yourself -- you didn't buy it.  You have licensed it.  If you check out
all the fine print somewhere, you'll see that you have a limited license to use
the software.

Also, if you look in that same fine print, you are probably going to find a
disclaimer of warranty that absolves your vendor of all liability, and that
explicitly disclaims any warrant of mechantability or fitness for any purpose.
I.e., the software may not do anything, but they aren't *legally* representing
it as supposed to be doing anything!

I don't think this is a proper way to do business, but it has become standard
in the industry.  There have been some cases where such warranty disclaimers
have been struck down in courts if the software failed to even boot up, but I
have never heard of the provisions being struck down for something like the
security bug leading to this discussion.

In general, if you were to purchase a car or TV or any other major
appliance, and in so doing had to sign a piece of paper that said
(effectively): 
  "You are not really buying this, you are leasing it.  You can't sell
   it or give it away without our permission, nor are you allowed to
   take it apart to see how it works.  We don't promise that it does
   anything in particular, despite what the salesman said.  If you try
   to use it and it fails, we're not responsible for any damages of
   any kind.  If really pressed, we'll exchange the item for a pile
   of the raw materials we used to construct it, at no charge to you.
   No other warranties are in effect on this item (except what may
   be in your state law) no matter what the salesman says -- we
   disavow any promises he made beyond this statement."
would you buy it?  We do it with software all the time.....

The problem has complex roots, beyond the scope of a short message
here: intellectual property, software specification and testing, and
poorly-informed consumers add to the problem.  We have cultivated a
professional and commercial attitude that is really like only 2 other
professions -- and they have state licensing imposed on them:
   "I'm sorry, we did everything we could to treat the infection, but
    he just didn't respond."
   "I'm sorry -- we gave it our best shot, but the jury didn't
    believe you."
   "I'm sorry -- we used state-of-the art methods, but you know how
    hard it is to find *every* bug."
 
The bottom line: by current definition and tradition, your vendor is not really
obliged to provide a fix unless you have a separate maintenance agreement.
Talk of a recall is "silly."  If you don't like it, you can always try to find
another vendor to whom you take your business.

Before any of you get too outraged by this, check carefully:
  *  If you sell a computer product, what do *you* disclaim?
  *  If you are a consumer, how many products have you bought
     this way without complaint?
  *  When have you conveniently blamed something on "the computer"?
 
Gene Spafford, NSF/Purdue/U of Florida, Softw. Eng. Research Center, Dept. of
Computer Sciences, Purdue University, W. Lafayette IN 47907-2004 (317) 494-7825

------------------------------

End of RISKS-FORUM Digest 11.15
************************