5-Jul-87 21:15:12-PDT,14540;000000000000
Return-Path: <NEUMANN@f4.csl.sri.com>
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) <RISKS@csl.sri.com>
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>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 <Walt Thode>
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. <eugene@ames-pioneer.arpa> [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 <pallas@pescadero.stanford.edu>
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 <mcvax!camcon!news@seismo.CSS.GOV>
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 <THOMPSON%BROWNVM.BITNET@wiscvm.wisc.edu>
Subject: Phone Company Billing Blunder
To: Risks Digest <RISKS@csl.sri.com>
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
************************
-------