The RISKS Digest
Volume 9 Issue 33

Sunday, 22nd October 1989

Forum on Risks to the Public in Computers and Related Systems

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

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


o Earthquake preparedness in computing
o Air-Traffic Disruptions
PGN and Robert Dorsett
o Railroad Level-Crossing Monitoring
Brian Randell
o Sometimes touch-screens aren't user-friendly
Jeffrey Mogul
o UK Banking Error
Brian Randell
o Quotron gores the bears and bares the bulls
o Quotron software timing error
David B. Benson
o Re: latest stock market crash
David Gursky
o Info on RISKS (comp.risks)

Earthquake preparedness in computing

"Peter G. Neumann" <>
Sun, 22 Oct 1989 12:35:32 PDT
Tuesday's Loma Prieta earthquake continues to have a devastating aftermath,
particularly in parts of Santa Cruz, Hollister, San Francisco and Oakland.
However, there have been some encouraging success stories of organizations with
computer/communication contingency plans that worked successfully following
Tuesday's earthquake (17 Oct 89).  Furthermore, it appears that the area was
spared much greater devastation because of anticipatory construction

The San Francisco Chronicle kept publishing despite a complete power outage at
the newspaper's headquarters, which ground their computer and main printing
facility to a halt.  Material for the Wednesday and Thursday editions was
assembled using Macintosh disks and an emergency generator.

There was building damage at SRI.  Most of the SRI Computer Science Lab
computer facility survived.  However, the RISKS file server was down until
Thursday; when it was resurrected, the disk on which RISKS operates was
discovered to be messed up as well, so I could not put an issue out until now.

Air-Traffic Disruptions [with contributions from Robert Dorsett]

"Peter G. Neumann" <>
Sun, 22 Oct 1989 12:24:07 PDT
For the second time in a week air traffic at Dallas-Forth Worth International
Airport was disrupted.  The Thursday 19 October computer outage (1950s-vintage
computer system) lasted at least twelve hours, and caused delays.  [Source:
Washington Post, 21 Oct 89, p22]

FAA officials said Thursday's breakdown happened when one of four data proces-
sors on the computer failed to start after routine maintenance.  The processors
feed specific information about each plane from the radar to the controllers'
screens.  Flights continued at a reduced rate during the outage.

The previous week's outage, on 14 Oct 89, lasted for 19 minutes.  It was traced
to a technician who mistakenly tried to program a radar computer from the wrong

Tony Dresden, a spokesman for the National Association of Air Traffic Control-
lers, said the FAA is trying to upgrade computer systems across the country.
But the process is painstakingly slow, he said.  "I think if you go to any
terminal across the country you'll find some older equipment mixed in with some
new equipment," Dresden said.  "So this is not just confined to terminals at
the Dallas-Fort Worth airport, but to terminals across the country."

Norm Scroggins, tower manager at D-FW airport says the FAA is looking into the
problem.  "We're in an interim mode," Scroggins said.  "I don't think it's
particularly useful that any government agency is unable to stay up with the
technological industry.  It's just hard to get the stuff in.  "And you have to
keep in mind that this same equipment is working quite well in Houston.  They
just don't have the demands that we (D/FW) have."

[Excerpted by PGN from an article from the The Austin-American Statesman, 21
Oct 89, provided by Robert Dorsett (@rdd@rascal.ics.UTEXAS.EDU)]

Railroad Level-Crossing Monitoring

Brian Randell <>
Tue, 17 Oct 89 19:08:36 BST
[This is interesting as an experiment in using AI - or more specifically neural
networks - in a safety-related application, though not in any safety-critical

The Independent, 17 Oct 1989, by Mary Fagan, Technology Correspondent

British Rail will use computers to monitor level crossings to see if cars
should be allowed to cross them, in an attempt to assess how artificial
intelligence and `computer vision' can be used more widely on the rail network.
As part of a major experiment to be announced today, computers emulating the
human brain will monitor the level crossings, deciding when it is safe to lower
and raise gates, and when cars and pedestrians should be allowed to pass

Dr Alan Cribbens, head of safety systems at BR, said such systems would be used
only to help and augment human control.  But he hopes computer vision and
artificial intelligence may also be used for examining the condition of rail
tracks and tunnels, and for inspecting the conditions of the brakes on rolling
stock.  `Computers would never be allowed to take decisions alone in the
primary safety loop, at least not in the short term.'

Level crossings are currently monitored by closed-circuit television and
controlled by an operator.  There is a limit as to how many crossings one
person can cope with, and the computer monitoring could dramatically increase
the efficiency.

The experiment also acts as a tough test for computer vision, because it has to
cope with variable lighting and weather, and to decide whether a scrap of paper
or rubbish on the track constitutes a serious obstruction.  The computer is a
`neural network' - a machine which attempts to emulate the way the brain works.
The network is made up of layers of tranputers, each of which is a computer in
its own right, and which represent a computer neuron or brain cell.

According to Colin Hebden of SD, the company supplying the system, the neural
network can be trained to recognise patterns and interpret images - things
which traditional number-crunching machines are not good at.  The transputer is
also ideal because it communicates well with other transputers in the ntework.

The BR experiment is said to be pushing forward the frontiers of neural network
computers.  `If it has potential we will have it in use as soon as possible,'
Dr Cribbens said.

Brian Randell, Computing Laboratory, University of Newcastle upon Tyne UUCP=...!ukc!!Brian.Randell

   [BR = British Rail, not Brian Randell.]

Sometimes touch-screens aren't user-friendly

Jeffrey Mogul <>
20 Oct 1989 1741-PDT (Friday)
Last night I went into a hardware store (Builder's Emporium in Redwood City,
CA) and walked past a kiosk providing advice from "Pop Larsen", probably a
fictional character.  In additional to little brochures ("How to unclog
drains") the kiosk contains a touch-screen system that apparently allows the
user to navigate through some menus to get home-repair information.

What caught my eye was that, superimposed on the flashy 3d-ish color
"buttons" on the screen, was a black & white message in a crude font:

    Overflow in line 0 of module 1W4200YC at
    address 328F:0501

    Hit any key to return to system

Of course, hitting "any key" was difficult, given that there were none.


UK Banking Error

Brian Randell <>
Fri, 20 Oct 89 12:53:44 BST
[I have used the hash symbol (#) for the pounds symbol. I am assuming that the
the story is using the term "billion" with its normal American meaning!  Brian

    Computer Weekly, Thursday 19 October 1989, p.1, by Tony Collins,

A UK bank has accidentally transferred #2bn to UK and US companies because a
software design flaw allowed payment instructions to be duplicated.  The
organisation has asked customers to return the money, which is more than the
annual profits of any clearing bank, but so far not all of the cash has been
recovered.  The error, described by the Computing Services Association (CSA) as
probably the most serious to have hit the IT industry, led to the #2bn being
paid out to customers over 30 minutes.

Within an hour the bank discovered its mistake, but by then the cash had been
transferred to other banks and into accounts of corporate customers in the UK
and US. The funds were sent on the high-speed Clearing House Automated Payment
System (Chaps) which allows high value payments, typically #2m, to be
transferred in seconds from one bank to another via a computer system linked
through British Telecom's Packet Switched Service.

Although Chaps refuses to name the bank it confirms that the accidental
transferral of #2bn occurred "in the past few weeks" and involved one of its 14
memeber banks. The membership includes all major clearing banks together with
the Bank of England, Girobank and the TSB.  Jim Reeves, Chaps technical
manager, says funds transferred on the network are guaranteed payments and are
technically irretrievable. "If a bank decides it has made a mistake, it is
still bound to settle the funds at the end of the day."  He adds that, as far
as he knows, most of the #2bn has been recovered as a result of the goodwill of
the close-knit banking community and its corporate customers.  "One bank
managed to send a number of payments it had sent the day before," says Reeves.
"It only noticed this because of a very high outflow of money early in the day.
It was a question of getting in touch with customers and asking them if they
minded payment going back."

Richard Allen, chief executive of the Association for Payment Clearing Services
(Apacs), which controls Chaps, says security and reliability have become
increasingly important in payment mechanisms, especially as more institutions
began using such systems.  "This is particularly so in high value mechanisms
such as Chaps," he says.  Reeves says the #2bn involved mostly foreign exchange
and money market transactions.

The error was due to a software flaw which allowed the system to choose a date
for payments rather than insisting that the operator made the selection.

In the event the system chose the wrong date.

The software has since been redesigned to avoid a repetition of the incident.

Brian Randell, Computing Laboratory, University of Newcastle upon Tyne UUCP=...!ukc!!Brian.Randell

Quotron gores the bears and bares the bulls. Oxidentally.

Peter G. Neumann <NEUMANN@CSL.SRI.COM>
Tue 17 Oct 89 15:36:20-PST
Following the wild drop on the NY Stock Exchange on Monday, Quotron reported at
10:30 AM on Tuesday, 17 October 1989, that the Dow Jones industrial average was
DOWN 71 points.  An unwitting NYSE VP announced this figure live on CNN, which
caused quite a stir.  However, almost all of the stocks (except the American
and United Airlines companies) were UP, and the average should actually have
been UP about 20 points.

Quotron gets live feeds from the market mainframes, and calculates the averages
every 15 seconds.  However, the heavy volume on the NYSE "overloaded" Quotron's
software.  The problem apparently corrected itself half an hour later.

"Nonetheless, the incident underscored how modern telecommunications have come
to tie investors and markets together around the globe and the threats to
market stability when the systems malfunction."  (John Burgess, Washington
Post, 17 October 1989)

Quotron software timing error

David B. Benson <dbenson@cs2.cs.WSU.EDU>
Wed, 18 Oct 89 15:48:45 PDT
Excerpts from:
    Traders Who Can't Believe Their Eyes Win Vindication
    Heavy Stock Volume Makes Some of Quotron's Data Veer
    Away From Reality
        by Georgette Jasen,
        Staff reporter of The Wall Street Journal
    The Wall Street Journal, October 17, 1989, page c23

    Traders ... were stunned to see the Dow Jones Industrial
    Average plummet 99 points in seconds.  A minute later
    it soared 128 points, then zoomed back down 113 points,
    69 below Friday's close.
    Quotron Systems Inc., a Citicorp unit, blamed the 30-minute
    foul-up on "a timing problem in our software" caused by
    the enormous early volume — about 145 million shares in the
    first hour of New York Stock Exchange trading.  The prices
    of the individual stocks that make up the average were correct,
    Quotron said, but the average was wrong. ...
    It was the second time in less than a week that Quotron has
    had problems calculating the industrial average. ...
[The earlier problem was attributed in a previous article to human error.]
    A Quotron spokeswoman said recent software changes may have
    contributed to yesterday's problems.  She said Quotron
    switched to a backup system until the problems were corrected.

Re: latest stock market crash

David Gursky <>
Tue, 17 Oct 89 21:50:35 EDT
In Risks 9.32, Olivier Crepin-Leblond <> asks if the 13
October 1989 drop in the average price of stocks on the New York Stock Exchange
could have been triggered by electronic vandalism of some form (he specifically
asks about a virus).

The possibility does exist, but (1) in this instance I do not believe that was
the case and (2) if it were the case, we would know about it by now I should

Friday's plunge (as I understand it) was caused by preprogrammed selling of
stock by computer.  The rules and conditions under which these programs
operate are well understood.  If those programs had made transactions "outside
of their envelope", the institutions that set the rules for the programs would
be screaming bloody murder, and we would see the SEC all over the evening news.

Expanding this a bit, I find it less than likely (although I doubt it is
impossible) for electronic vandalism (viruses, logic bombs, or time bombs) to
effect these applications unnoticed.  [I might add that when I say "less than
likely", the basis of my comparison is the computing community in general,
which is far more open than the NYSE's computers.]  Again, preprogrammed
trading occurs only under known conditions.  It should be possible to put in
some minimal amount of safeguards to prevent these automated trades to occur
outside of their defined envelopes.  This is not to say NYSE has done so

Please report problems with the web pages to the maintainer