The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 16 Issue 72

Friday 6 January 1995

Contents

o Computing error at Fidelity's Magellan fund
Kathy Godfrey
Arthur Flatau
o Phone system problems in Santa Fe
Bruce Wampler
o LZW/GIF flap on RISKS
Tim Oren
o Re: CompuServe-Unisys GIF Tax Protest
Peter Bishop
o Software math errors
Chris Phoenix
o Rutherford Effect: term for particular class of failures
Bill Thomas
o Re: Cancelbot Derails Online Promo
Andrew Haley
o Re: Soldiers and Cellular Telephones
Linden B. Sisk
o Re: Computer Addiction
Mary Shafer
John C. Rivard
Steven D. Brewer
o Re: Date and Time
Leslie Lamport
o Info on RISKS (comp.risks)

Computing error at Fidelity's Magellan fund

Kathy Godfrey <kgodfrey@BBN.COM>
Wed, 4 Jan 95 17:44:41 EST
There was a big flap recently over Fidelity's Magellan fund estimating in
November that they would make a $4.32/share distribution at the end of year,
and then not doing so.  A letter of explanation was sent to the shareholders
(including me) from J. Gary Burkhead, the President of Fidelity, including
the following pertinent items:

"During the estimating process, a tax accountant is required to transcribe
the net realized gain or loss from the fund's financial records (which were
correct at all times) to a separate spreadsheet, where additional
calculations are performed.  The error occurred when the accountant omitted
the minus sign on a net capital loss of $1.3 billion and incorrectly treated
it as a net capital gain on this separate spreadsheet.  This meant that the
dividend estimate spreadsheet was off by $2.6 billion....

"Some people have asked how, in this age of technology, such a mistake could
be made.  While many of our processes are computerized, the requirements of
the tax code are complex and dictate that some steps be handled manually by
our tax managers and accountants, and people can make mistakes.  The error
in this case was not caught in the initial review, but was detected in our
normal process--which includes a review by outside auditors--as we prepared
to make the actual distribution calculation.

"We have taken several steps designed to ensure that this error should not
happen again.  We will subject initial estimates to the same rigorous
verification process that we use in preparing the distributions that the
funds actually pay.  This will include a thorough review not only by our own
fund accountants by also by the fund's treasurer and independent auditors.
In addition, estimates will be reviewed by each fund's portfolio manager."

I'm still not clear as to exactly why a spreadsheet or other program
couldn't be developed to make the estimation calculation, since the problem
seems to have been a transcription error and not a failure to understand the
complexities of the tax code.  It also occurred to me to wonder what sort of
testing the software they do use undergoes, and whether those procedures
will also be upgraded in the wake of this mistake.

I see two RISKS: The implication that this mistake only happened because
manual steps were involved, and the risk of having infrequent but highly
important tasks that require non-standard procedures (like "manual"
calculations in a largely computerized environment).

<>Kathy Godfrey    kgodfrey@bbn.com


Only Wimps use minus signs (Magellan/Fidelity Investments)

Arthur D. Flatau <flatau@cli.com>
Fri, 6 Jan 95 12:31:47 CST
   [Arthur sent us an excerpt from the 5 Jan 1995 edition of the *Austin
   American Statesman*, p D8 (omitted here), with the following comment.  PGN]

Even after reading risks all these years, I am still amazed that these kind
of errors can slip by.  The last time I entered a $1.3 billion check as a
deposit in my checkbook, it was only a short time before I was bouncing
checks left and right.  It also was quite apparent when I balanced my check
book at the end of the month.

Art   flatau@cli.com  Austin, Texas


Phone system problems in Santa Fe

<wampler@cs.unm.edu>
Thu, 5 Jan 95 10:46:12 MST
>From the January 4, 1995 Albuquerque Tribune front page:

Hello? Hello? Phones go haywire in Roundhouse

  Your state government has been disconnected. Please check the
number and call again some other time.
  As if Gov. Gary Johnson's call for the mass resignation of about
350 state officials weren't enough to confuse citizens in search of
bureaucrats, the state's phone system on Tuesday began to arbitrarily
shifting many 827-prefix calls to an erroneous recording that declared
the number was not in service.
  The 827 prefix is state government's main prefix in Santa Fe.
  "I'm quite uncomfortable about the current situation," John Dawson,
deputy director of the state Office of Communications, said Tuesday.
"It's manifesting itself very seriously today for some reason. But
I'm hopeful that it will be over in the next 24 hours."
  Dawson said a glitch in the software that controls the state office
phone system was at fault for the complications.  He said it appeared
to be affecting only Santa Fe offices with the 827 prefix.
  The state was aware of the computer problem a year ago, and removed
the software because of it, he said.  But two weeks ago the state
allowed its contractor, Fijitsu Business Communication Systems, to
reinstall the software because the glitch supposedly had been removed."


The article went on to describe the confusion, and the fact that our new
governor was not getting calls.  As might be expected, this happened right
when a new administration was moving in to Santa Fe. So, if it was broken
once, try to break it again at the most critical time possible. Sigh...

Bruce Wampler, Ph.D.  Adjunct Professor, Department of Computer Science
University of New Mexico  wampler@cs.unm.edu


LZW/GIF flap on RISKS

Tim Oren <oren@well.sf.ca.us>
Tue, 3 Jan 1995 22:15:24 -0800
  [A longer message from Tim is floating around the well.  This one seems
  quite succinct, and helps to clarify further the situation discussed in
  RISKS-16.69 and .70.  PGN]

Because the RISKS list gets pretty wide distribution, I wanted you to know
that the original posting contains some pretty serious misinterpretation of
a messy situation.  Briefly,

- CompuServe is asserting no proprietary rights in the GIF spec, and couldn't
even if we wanted to, since it has long been openly published.

- The LZW algorithm was incorporated from an open publication, and without
knowledge that Unisys was pursuing a patent.  The patent was brought to our
attention, much to our displeasure, after the GIF spec had been published and
passed into wide use.

- We found it necessary to take a license to the patent from Unisys, and
since a number of our developers had used GIF in good faith, we also
negotiated a pass-through license for their benefit.  Clawson has
distributed parts of this license, with a poor interpretation, outside of
its original context, which was to developers of CompuServe-related products
alone.  GIF is included in this license because we are unable to pass
through a general license to practice LZW.

- It is not the intent of CompuServe to attempt to enforce proprietary
rights in GIF against users or developers, including those of Web
technology.  We cannot and do not speak for Unisys' intent in this matter.

- Having and transmitting GIF images is not an infringement of the patent,
since 'practicing' LZW means running code which accomplishes the compression
of the graphics.

Tim Oren,  Vice President, Future Technology  CompuServe, Inc.


Re: CompuServe-Unisys GIF Tax Protest

Peter Bishop <p_bishop@adelard.demon.co.uk>
Thu, 05 Jan 95 18:01:30 GMT
The recently announced patent restriction by UNISYS/COMPUSERVE on the
use of GIF files poses a potentially serious problem. The Internet
community needs to protect itself from such arbitrary constraints by
establishing a new public domain standard for graphics interchange.

This standard needs to:

1) Be compact
2) Decode fast
3) Be free from patent/copyright restrictions
4) Be rapidly available

JPEG is certainly a candidate as it is a public standard. The only
drawback is the slow decoding time.

However there is an alternative based on existing 'standards'
that should give similar performance to GIF files.
We can do this by:

a) Representing the picture using the Portable Bit Map (PBM) format

b) Compressing using the Free Software Foundation GZIP method.

I have being trying this idea out to see if the performance is OK.
Unfortunately I do not have PBM support on my machine, but I have
been testing the approach using the Windows bitmap format (BMP).
The tests were done on an PC 386/DX33 machine using 8 bit (256 color)
files. The GIF and JPEG measurements were based on the LVIEW 3.1
public domain graphics package. Standalone DOS GZIP and PKZIP v1.1 packages
were used for the other measurements.

Results:

Test file Cathedra.bmp

Format  Size (bytes)       Encode (secs)      Decode (secs)

BMP     307,994                -                  -
ZIP     185,866               14                  6
GZ      173,314               15                  6

GIF     197,548                8                  9
JPEG     56,167               25                 30


Test file simba.bmp

Format  Size (bytes)       Encode (secs)      Decode (secs)

BMP     265,398                -                  -
ZIP     109,760               15                  5
GZ       99,748               14                  4

GIF     113,895                9                  8
JPEG     34,638               21                 20

Assuming that BMP and PBM formats are of similar size, it would seem that a
compressed PBM file format (GZF?) has advantages over the equivalent GIF
file since it is smaller and decodes faster. The encoding time is slower -
but this is a 'one-off' operation so it is not too important.

It is also interesting to note that GZIP gives better compression than my
rather elderly V1.1 version of PKZIP, and I think that GZIP will stand up
pretty well against current compression methods such as those in PKZIP 2.04.

I hope this starts a useful debate on defining a 'rapid hack' to provide a
substitute for GIF format files.

Obviously it is important that we get something that people are happy with -
but quickly. One option is to set up a forum of current GIF providers and
users who would hammer out a new format.  The other more direct (and rapid)
approach is to nominate a volunteer to define the format and provide the C
sources so that the new format can be readily incorporated into existing
graphics tools.

The obvious choice here is the Free Software Foundation.  It is part of
their remit to provide good quality free software, and they are the authors
of GZIP, so they should be in a good position to define the format and
publish it via the usual GNU distribution channels (together with a GIF to
GZF converter).

Peter Bishop, Adelard, 3 Coborn Rd, London E3 2DA, England
Tel  : +44-81-983-0219      p_bishop@adelard.demon.co.uk


Software math errors

"Chris Phoenix" <Chris.Phoenix@efi.com>
Wed, 4 Jan 1995 18:18:00 -0800
Along with the historical-interest postings on hardware math errors, it may
be interesting also to consider software math errors.  Here's one:

The built-in BASIC on the TI 99/4A computer uses a certain shortcut for
boolean calculations: it uses * for and and + for or.  Operations such as ">"
return numeric values, and the IF statement tests for zero or non-zero.
Here's the problem: the 'numeric values' mentioned above are 0 for false,
and -1 for true.
 So `` 10 IF (((1 > 0) * (1 > 0)) + (1 > 0)) PRINT "It Works" ''  won't print
anything, since -1 * -1 is 1, and 1 + -1 is 0.

Chris Phoenix     chris@efi.com     415-286-8581


Rutherford Effect: term for particular class of failures

Bill Thomas <billt@core.rose.hp.com>
Wed, 4 Jan 95 20:38:30 PST
While resolving a problem involving interactions of multiple systems we
found we had a set of failure conditions which had a very low probability of
happening, lacked any work around or avoidance strategies, and had very
unexpected results when one occurred.  We gave the name "Rutherford Effect"
to such situations.

The reason for the name "Rutherford Effect" comes from the experiment
Rutherford and two of his students, Geiger and Mardsen did.  They made a
beam of particles project onto a thin metal foil.  Most particles when
through with no problem.  However, a few hit the nucleus in of a atom in the
foil and bounced back.  According to legend, Rutherford said, "I would not
have been more surprised if I had shot a cannon ball at tissue paper and it
bounced back."  The similarity of a computer mostly working but having a
very small number of unpredictable and unavoidable failures inspired us to
say it suffered from a "Rutherford Effect".

The Pentium also suffers from a Rutherford Effect.

Bill Thomas   billt@core.rose.hp.com


Re: Cancelbot Derails Online Promo (WSJ via Edupage 12/20/94)

Andrew Haley <aph@atml.co.uk>
Thu, 5 Jan 1995 13:57:27 GMT
The excerpt from the _Wall Street Journal_ about this incident reproduced in
RISKS-16.67 is inaccurate.

This incident involved Michael Wolff posting nearly 150 virtually identical
messages to different newsgroups.  (Actions of this kind are called
"spamming", where "spam" is defined as the posting of 20 or more
substantially identical messages to Usenet.  The content of these messages
is irrelevant.)  These messages were cancelled by Cancelmoose.

After the cancellation, the issue of these messages was discussed at
length in alt.current-events.net-abuse, and a vote was taken, which
was overwhelmingly in favour of the cancellation.  There was nothing
special about the Wolff postings; all mass postings to Usenet that fit
the criteria of spam are cancelled.

Cancelmoose is not a "vigilante", as he does not act alone; there is
substantial agreement amongst the Usenet administrators that have
contributed to this debate that these actions are necessary.

Wolff claims to be an expert on the Internet; if this were true he
shouldn't have been "stunned and amazed" by the response.

Andrew


Re: Soldiers and Cellular Telephones

Linden B. Sisk <sisklb@texaco.com>
Thu, 5 Jan 95 09:47:41 CST
Cellular phones, when powered up, periodically transmit to the nearest cell,
even when someone is not talking on them.  For soldiers, that represents a
risk that enemy troops will be able to locate them using direction- finding
equipment and attack them, or call in artillery fire or air strikes on their
position.  That, I presume, is why the Israeli command structure is
concerned about their troops carrying cell phones - and should be -
notwithstanding the issue of time being spent on non-military tasks.

Linden B. (Lindy) Sisk  sisklb@texaco.com


Re: Computer Addiction

Mary Shafer <shafer@nasp.dfrf.nasa.gov>
Wed, 4 Jan 95 17:18:53 PST
Try the "leave" command if you're a UNIX person.  It not only warns you that
the time to logout is coming up, but proceeds to nag you after the set time
passes.

I've been using this since about 1988, since I'm in a carpool.

Mary Shafer, SR-71 Chief Engineer, NASA Dryden Flight Research Ctr, Edwards, CA
shafer@dfrc.nasa.gov  URL http://www.dfrc.nasa.gov/People/Shafer/mary.html


Re: Computer Addiction (Kabay, RISKS- 16.70)

John C. Rivard <jcr@garnet.msen.com>
Wed, 4 Jan 1995 21:43:43 -0500
Actually, there was (and perhaps still is) such a product for the Apple
Macintosh called LifeGuard.

It was reviewed in the February 1991 issue of _MacUser_ magazine. According
to the reviewer, the memory-resident program produced an audible and visual
alarm on the Mac after a length of time that the user specifies. It then
reminded the user to take a break:

  "You control the frequency of breaks as well as the interval allowed before
  it's time to resume work."

It also provided the user with a "snooze" function to temporarily override
the alarm. It even offers suggestions for exercises and basic information on
ergonomics, according to the reviewer.

LifeGuard's  publisher was Visionary Software, Inc., P.O. Box 69447,
Portland, OR 97201 (800-877-1832 or 503-246-6200). I have never actually
seen the product, just read the review. I wonder if it caught on and
whether it is still available today (version 1.0 was reviewed).

John C. Rivard          jcr@garnet.msen.com       JCR Design and Consulting
Copyright (c)1994 John C. Rivard (just in case) :^)


Re: Computer Addiction

Steven D. Brewer <brewer@cs.wmich.edu>
Thu, 5 Jan 95 13:37:55 EST
Such things already exist.  Coffee Break, a program for the Mac by Thomas
Reed, was written to help reduce repetitive stress injuries.  It allows you
to set how much time you want to work between breaks and how long your
breaks should be.  It will then come to the foreground when you have
exhausted your work time and will not relinquish control of your computer
until after the break time has passed.  I haven't used the program myself
and can't speak in any detail about its features.  It is available from the
typical Mac ftp sites (I downloaded it from the umich archives:
/mac/util/organization/coffeebreak1.1.sit.hqx.)

Steve Brewer <brewer@cs.wmich.edu>  http://141.218.91.93/WWW/I_sbrewer.html
Science Studies WMU Kalamazoo MI 49008


Re: Date and Time (Leichter, RISKS-16.71)

<lamport@pa.dec.com>
Thu, 05 Jan 95 15:57:51 -0800
Jerry Leichter said

   Leslie Lamport published an algorithm a couple of years back - essentially
   the trick that others have mentioned, of reading high order, then low order,
   then high order again, and retrying if the high order bits changed - that
   can be proved to get the correct time without requiring interlocking.
   The proof is non-trivial.

Despite the assortment of trivialities that have been published as
"Lamport's bakery algorithm", I am still not inured to the defamation of my
algorithms.  Please inform the Risks list that my clock-reading algorithm,
published in

   AUTHOR = "Leslie Lamport",
   TITLE = "The Concurrent Reading and Writing of Clocks",
   journal = tocs,
   volume = 8,
   Number = 4,
   Month = nov,
   Year = 1990,
   pages = "305--310"

requires no retrying.

Leslie

Please report problems with the web pages to the maintainer

Top