5-Jul-87 21:15:12-PDT,14540;000000000000 Return-Path: Received: from csl.csl.sri.com (CSL.SRI.COM) by F4.CSL.SRI.COM with TCP; Sun 5 Jul 87 21:12:07-PDT Received: from F4.CSL.SRI.COM by csl.csl.sri.com (3.2/4.16) id AA19132 for RISKS-LIST@f4.csl.sri.com; Sun, 5 Jul 87 21:04:04 PDT Message-Id: <8707060404.AA19132@csl.csl.sri.com> Date: Sun 5 Jul 87 21:11:25-PDT From: RISKS FORUM (Peter G. Neumann -- Coordinator) Subject: RISKS DIGEST 5.7 Sender: NEUMANN@csl.sri.com To: RISKS-LIST@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Sunday, 5 July 1987 Volume 5 : Issue 7 FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Actual stock price change fails sanity check (Mark Brader) PacBell service "glitch" (Walt Thode) NASA Safety Reporting System (Jim Olsen) "Information Tax" -- Risks of nonsense (Joseph I. Pallas) "Computer woes hit air traffic" (Davis) Re: Aircraft Transponders and O'Hare AIRMISS Phone Company Billing Blunder (Steve Thompson) Relaxed DOD Rules? (Dennis Hamilton) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM. FTP back issues Vol i Issue j from F4.CSL.SRI.COM:RISKS-i.j. Volume summaries for each i in max j: (i,j) = (1,46),(2,57),(3,92),(4,97). ---------------------------------------------------------------------- Date: Mon, 29 Jun 87 13:00:34 EDT From: msb@sq.com (Mark Brader) To: risks@csl.sri.com Subject: Actual stock price change fails sanity check In the 1880's the Canadian Pacific Railway wanted a line between Montreal and Toronto but could neither afford to build one nor to buy out an existing railway. So what they did was to take a perpetual lease on an existing railway, the Ontario and Quebec. Later they did buy up O&Q stock until they held 80% of it. Along with the O&Q came land in Toronto and Montreal that is now of great value. Over the years the CPR sold off this land. Finally someone noticed that they didn't really own it, bought up some O&Q shares, and brought suit against the CPR. The case was appealed to the Supreme Court of Canada. Just before the court decision the O&Q shares were valued at $15,000 (Can.) each. A ruling for the O&Q would likely raise that by a factor of 10 or more -- and a ruling for the CPR would drop it by a factor of 10 or more! The court ruled for the CPR, and the stock dropped $14,100 per share in one day (and more the next day). But there was no entry in the stock market columns for this remarkable change (the stock was listed as not traded). According to the Toronto Star, "a Toronto Stock Exchange computer interpreted the sharp drop reported by stockbrokers as an error". ------------------------------ Date: 30 June 1987 1612-PDT (Tuesday) From: thode@nprdc.arpa To: risks@csl.sri.com Subject: PacBell service "glitch" From the June 30 Edition of the San Diego Union: PacBell's Service is Disrupted: Computer glitch snarls multitude of 619 area calls A computer program glitch disrupted telephone service in San Diego and Imperial Counties for several hours yesterday, potentially affecting all 1.1 million Pacific Bell customers in the two-county area. The breakdown came on the busiest workday of the year's busiest telephone season. A major malfunction in the computerized switching equipment at the company's main station in Hillcrest prevented many long-distance calls from going through the 619 area code, Pacific Bell spokesmen said. Affected were both local and long-distance toll calls. Pacific bell noticed calls backing up on its monitor at around 9:30 AM. By late afternoon, technicians had traced the problem to a mysterious foul-up in the programs -- the only part of the enormous computer, installed in 1984 and working since without a hitch, that has been updated frequently, a company spokesman said. The system was shut down at 10:56 AM for 152 seconds -- a record. Then the computer had to be reloaded, trunk line by trunk line, while the search continued for the problem. By 6 PM, most of the system was back in service. (The story goes on to describe the local impact, especially on the long-distance companies who weren't at fault.) ------------------------------ To: RISKS@csl.sri.com From: olsen@XN.LL.MIT.EDU (Jim Olsen) Subject: NASA Safety Reporting System Date: Tue, 30 Jun 87 17:59:56 EDT >From: Eugene Miya N. [RISKS-5.5] >NASA has established a voluntary, confidential safety reporting system ... For many years, NASA has operated the Aviation Safety Reporting System (ASRS) for the FAA. It has been quite successful, producing important information about flight safety. The ASRS has two key features to encourage participation: immunity and confidentiality. When someone reports an incident to the ASRS, he/she gains immunity from FAA disciplinary action for inadvertent errors associated with it (deliberate actions are not protected). NASA ensures confidentiality by separating the identifying information from the report during initial processing. The reporter receives a numbered receipt which can be used to prove that he/she reported the incident to ASRS. Without the receipt, the reporter cannot be identified. The ASRS works because it offers an inducement for reporting (immunity), and provides reliable confidentiality. It probably helps that the program is operated by a trusted, independent agency. ------------------------------ Date: Sat, 27 Jun 87 11:23:43 pdt From: Joseph I. Pallas Subject: "Information Tax" -- Risks of nonsense To: risks@csl.sri.com The notion that the proposed access charges for enhanced service providers represents some kind of "information tax" seems to be remarkably popular. Of course, it's total nonsense. The FCC is merely suggesting that Tymnet, Telenet, etc. no longer be exempt from the access charges that all other services (e.g., long distance voice) must pay for connection to the local telephone network. The original exemption was to protect a "fledgling industry." Whether the industry can now compete on an equal basis with AT&T and MCI remains to be seen. The computer-related risk here seems to be in how easy it is to forget that our networks are being heavily subsidized by both private and public money. joe ------------------------------ Date: Sun, 28 Jun 1987 13:33 EDT From: DAVIS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU To: RISKS@csl.sri.com Subject: "Computer woes hit air traffic" [Boston Globe, Monday, June 15, 1987] RISKS-5.5 reprinted part of a newspaper story: Boston (AP) - "A computer problem that blanked the radar screens of air traffic controllers from New England to the Great Lakes for six minutes delayed flights at Logan International Airport, but posed no hazard, an official said.... This is at best vague and pointlessly inflammatory; at worst it's nonsense. The key question is: was more than one installation affected? What exactly does "from New England to the Great Lakes" mean? If they mean more than one site, how could that have happened? Are ATC computers networked together in such a way that a crash can propagate? (I doubt it; as I understand it they're too old to know about things like networks). If not networks, then perhaps it was a common mode power failure. At sites several hundred miles apart? I doubt it. If more than one site, then why were only the Logan flights delayed? How exactly could more than one site be affected at the same time and for the same duration? And in what conceivable sense was it "a computer problem"? A common mode software bug? One that bit all the places at the same instant? It's considerably more likely that what they really meant was something like "One computer failed today for six minutes at Logan airport." Presumably the longer-range radar at Logan tracks some flights as far as Lake Ontario (about 500 mi). It's also possible that there are ATC centers in Montreal, Toronto, Buffalo, Detroit, New York, Cleveland, Columbus, etc. etc., (all within the same 500 mi. range) that were capable of tracking those flights, in addition to the backup system mentioned in the story. It's also interesting that there's still sufficient flexibility in the ATC system that simply slowing things down handled the problem. The problem is that "One air traffic control system halted for six minutes today at Logan airport" and "it didn't matter at all," just isn't much of a story. Not nearly anxiety producing enough; not nearly technophobic. Imagine the same story written with a slightly different viewpoint: "The reliability of our rather old ATC system was demonstrated today when the system at Logan airport failed completely for six minutes. Even though flites as far as 500 miles away were affected, the problem was easily handled by the existing procedures for slowing down some flights and keeping others on the ground, made possible by the routine use of backup communication systems designed for this purpose." There are as I understand it abundant problems in getting ATC done right, ranging from reliable sw and hw to reliable organizations of people and alignment of responsibilities. It's best we attend to the real problems and try to discourage nonsense like this. Tell your local newspaper they really do have to get the facts correct. [You can always tell a newspaper man, but you can't tell him much! PGN] ------------------------------ To: comp-risks@ukc.ac.uk From: news Subject: Re: Aircraft Transponders and O'Hare AIRMISS Date: 25 Jun 87 13:01:43 GMT Organization: Cambridge Consultants Ltd., Cambridge, UK The airmiss was allegedly due to the display equipment not showing details of an aircraft because it had a duplicate SSR transponder code... But aircraft without an assigned code all have the same code (1234 in UK, 1200(?) in US); similarly emergency traffic all uses a small number of not-guaranteed-unique codes; so this can't be the entire explanation... (one hopes!) ------------------------------ Date: Fri, 03 Jul 87 17:34:45 EDT From: Steve Thompson Subject: Phone Company Billing Blunder To: Risks Digest The following letter is from the syndicated column by advice-giver Ann Landers, which I saw in the 1 July 1987 (Providence, RI) *Journal*. Though it addresses real RISKs concerns, I include it more for its giggle value. PHONE COMPANY GIVES SOMETHING FOR NOTHING Dear Ann, I think I can top the person who wrote complaining about the idiocy of the phone company. Talk about garbage in, garbage out! When AT&T split with Bell, we had three phones in our house. The equipment belonged to Ma Bell and the service belonged to AT&T. After we returned all the phone equipment to Ma Bell, we received a bill for $0.00. A few weeks later, we received a check for $5 and a note thanking us. Several months later, we received another computerized bill for $0.00. We called again, got nowhere, so we sent another check for $0.00. A few weeks later we received another $5 refund with the same thank you. This went on every three months for two years. Now we are down to once a year and have given up trying to straighten this out. We just cash the $5 and forget about it. -- Linda K. R. in California Stephen W. Thompson, User Services Specialist, User Services Brown U., Box P, Providence, RI 02912 USA Smile! THOMPSON%BROWNVM@WISCVM.WISC.EDU (401) 863-3619 ------------------------------ Date: Sat, 4 Jul 87 20:57:32 EDT From: rlgvax!cci632!sjfc!deh0654@seismo.CSS.GOV (Dennis Hamilton) To: seismo!csl.sri!RISKS@seismo.CSS.GOV Subject: Relaxed DOD Rules? Cc: J.SNELL%BROCK1P.bitnet@csl.sri.com Cc: rochester!seismo!Xerox.COM!WAnderson.wbst Here's something to chew on. %T DOD Gives Software Developers More Leeway In Writing Code %J Electronics %V 60 %N 12 %P 99 %D June 11, 1987 %O Military/Aerospace Newsletter (department) %K SDS 2167/A Top-Down Methodology Waiver %X Military contractors no longer will be forced to use top-down methodology -- in which design and coding of computer programs use a hierarchical structure -- when developing software for the Department of Defense. The Pentagon has revised its two-year-old Defense System Software Development Standard, designated 2167, and will issue the new version, 2167/A, on June 30. The document spells out what the DOD expects from software contractors and gives them more leeway in writing code than the original standard. Although the DOD revised 2167 in response to industry dissatisfaction with the standard, some software suppliers are calling for further changes, such as provisions for rapid prototyping. Howard L. Yudkin, president of the Software Productivity Consortium, a Reston, Va., group respresenting 14 aerospace companies, is pushing for an industry position on where and how to use and not use 2167. The DOD, he says, should "recognize Standard 2167 as good for the engineering development phase for which it was intended, but not for advanced development." The Pentagon's Computer Software Management Subgroup, the joint-services committee responsible for 2167 revisions and compliance, believes that 2167 coverage of rapid prototyping is premature, according to Air Force Capt. Rick Schmidt, committee chairman. %X That is the entirety of the announcement. Having not seen the revised standard (and not being a follower of the original, for that matter), I can't ascertain whether this is a dangerous situation or not. But it reminds me that the reputation of the Go To is being restored in the letters sections of Communications of the ACM, also. -- Dennis E. Hamilton ------------------------------ End of RISKS-FORUM Digest ************************ -------