Subject: RISKS DIGEST 16.72 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Friday 6 January 1995 Volume 16 : Issue 72 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** Contents: Computing error at Fidelity's Magellan fund (Kathy Godfrey, Arthur Flatau) Phone system problems in Santa Fe (Bruce Wampler) LZW/GIF flap on RISKS (Tim Oren) Re: CompuServe-Unisys GIF Tax Protest (Peter Bishop) Software math errors (Chris Phoenix) Rutherford Effect: term for particular class of failures (Bill Thomas) Re: Cancelbot Derails Online Promo (Andrew Haley) Re: Soldiers and Cellular Telephones (Linden B. Sisk) Re: Computer Addiction (Mary Shafer, John C. Rivard, Steven D. Brewer) Re: Date and Time (Leslie Lamport) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Wed, 4 Jan 95 17:44:41 EST From: Kathy Godfrey Subject: Computing error at Fidelity's Magellan fund 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 ------------------------------ Date: Fri, 6 Jan 95 12:31:47 CST From: flatau@cli.com (Arthur D. Flatau) Subject: Only Wimps use minus signs (Magellan/Fidelity Investments) [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 ------------------------------ Date: Thu, 5 Jan 95 10:46:12 MST From: wampler@cs.unm.edu Subject: Phone system problems in Santa Fe >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 ------------------------------ Date: Tue, 3 Jan 1995 22:15:24 -0800 From: Tim Oren Subject: LZW/GIF flap on RISKS [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. ------------------------------ Date: Thu, 05 Jan 95 18:01:30 GMT From: p_bishop@adelard.demon.co.uk (Peter Bishop) Subject: Re: CompuServe-Unisys GIF Tax Protest 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 ------------------------------ Date: Wed, 4 Jan 1995 18:18:00 -0800 From: "Chris Phoenix" Subject: Software math errors 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 ------------------------------ Date: Wed, 4 Jan 95 20:38:30 PST From: Bill Thomas Subject: Rutherford Effect: term for particular class of failures 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 ------------------------------ Date: Thu, 5 Jan 1995 13:57:27 GMT From: Andrew Haley Subject: Re: Cancelbot Derails Online Promo (WSJ via Edupage 12/20/94) 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 ------------------------------ Date: Thu, 5 Jan 95 09:47:41 CST From: sisklb@texaco.com (Linden B. Sisk) Subject: Re: Soldiers and Cellular Telephones 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 ------------------------------ Date: Wed, 4 Jan 95 17:18:53 PST From: shafer@nasp.dfrf.nasa.gov (Mary Shafer) Subject: Re: Computer Addiction 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 ------------------------------ Date: Wed, 4 Jan 1995 21:43:43 -0500 From: jcr@garnet.msen.com (John C. Rivard) Subject: Re: Computer Addiction (Kabay, RISKS- 16.70) 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) :^) ------------------------------ Date: Thu, 5 Jan 95 13:37:55 EST From: brewer@cs.wmich.edu (Steven D. Brewer) Subject: Re: Computer Addiction 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 http://141.218.91.93/WWW/I_sbrewer.html Science Studies WMU Kalamazoo MI 49008 ------------------------------ Date: Thu, 05 Jan 95 15:57:51 -0800 From: lamport@pa.dec.com Subject: Re: Date and Time (Leichter, RISKS-16.71) 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 ------------------------------ Date: 22 December 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not yet automated). SUBJECT: SUBSCRIBE or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. CURRENT ARCHIVES: "ftp unix.sri.comlogin anonymousYourName cd risks or cwd risks, depending on your particular FTP. Issue J of volume 16 is in that directory: "get risks-16.J". For issues of earlier volumes, "get I/risks-I.J" (where I=1 to 15, J always TWO digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory and I subdirectory; "bye" I and J are dummy variables here. REMEMBER, Unix is case sensitive; file names are lower-case only. =CarriageReturn; UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. Risks can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html (Please report any format errors to Lindsay.Marshall@newcastle.ac.uk) FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot send E-mail to risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.72 ************************