Text File

12-Jun-87 08:04:47-PDT,17212;000000000000 Mail-From: NEUMANN created at 12-Jun-87 08:03:40 Date: Fri 12 Jun 87 08:03:40-PDT From: RISKS FORUM (Peter G. Neumann -- Coordinator) <RISKS@CSL.SRI.COM> Subject: RISKS DIGEST 5.2 Sender: NEUMANN@CSL.SRI.COM To: RISKS-LIST@CSL.SRI.COM

RISKS-LIST: RISKS-FORUM Digest Friday, 12 June 1987 Volume 5 : Issue 2

FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents: Three gremlins on the loose: nukes, sharks, enlightened rockets (Dave Platt) Yet another air-traffic-controller foul-up (Roy Smith) National Crime Information Center access (PGN) Yes, Virginia, There Are Software Problems (Nick Condyles) Heisenbugs; Also, Risks of Supercomputers (Eugene Miya)

[There is more submitted material pending, but this is all I had time for. CSL.SRI.COM is being transformed for the next few days. Please bear with any inconveniences. By next week all changes should have been completed, advertised as "completely transparent." (Don't hold your breath.)]

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) Back issues Vol i Issue j available in 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: Thu, 11 Jun 87 08:08:13 pdt From: dplatt@teknowledge-vaxc.ARPA (Dave Platt) To: risks@csl.sri.com Subject: Three gremlins on the loose: nukes, sharks, enlightened rockets

[Whereas the following three incidents are not directly computer related, they are clearly RISKS related, providing further examples of the unexpected technical failures. On examining my list of collected cases, I am astounded to discover how many of the cases were due to causes that (a) had never occurred before and (b) no one had even anticipated might occur. PGN]

This morning's San Jose Mercury News contains three interesting articles, almost one-after-another. Their headlines, and a summary of their contents:

* "Official says many U.S. atom bombs are faulty"

More than one of every three nuclear weapons in the U.S. arsenal doesn't work properly, [Sylvester Foley, asst. sec. of energy for defense programs] said yesterday [during a breakfast meeting with reporters].

"Hypothetically, it could be catastrophic if you ever wanted to use it and you pushed the button and nothing happened", said Foley.

{ no comment... dcp }

* "Jaws V: Sharks make light lunch of trans-Atlantic fiber-optic cables"

Sharks seem to have taken a fancy for the new 1"-thick underwater cables being strung across the Atlantic; they've bitten through the cable at least four times (cost-to-repair $250,000 per bite). Similar bitings have been reported in the Pacific. Older-style copper-wire cables apparently weren't attractive to sharks, and weren't bitten.

[The NYTimes article suggests that the sharks seem to be attracted to the low electrical currents in the copper wires providing power for the fiberoptic repeaters. The new cables are still shielded, but much thinner than previously. PGN]

* "Lightning hits NASA launch pad inadvertently setting off 3 rockets"

A lightning strike on a pad at NASA's launch facility at Wallops Island, VA. ignited three small rockets and sent two of them hurtling along their planned trajectories; they were more than two miles out before the NASA officials could prepare to track them. The third rocket wasn't in firing position, and splashed down in the ocean 300 feet from the pad. It appears that a lightning bolt may have induced a current pulse in the firing leads, triggering the igniters.

One of the rockets was scheduled to have been launched shortly thereafter to study night-time thunderstorms and their effect on the atmosphere.

[The weather-satellite ground station was also affected, despite surge suppressors and grounding wires that were supposed to protect it. Weather data from GOES-West could not be received for 9 hours, and GOES-East was blacked out for 5.5 hours. NYTimes, same day. PGN]

------------------------------

From: cmcl2!phri!roy@seismo.CSS.GOV (Roy Smith) Subject: Yet another air-traffic-controller foul-up Date: 9 Jun 87 20:24:16 GMT

From the NY Times, June 9, 1987, page A22: "Coding Error at O'Hare Brings Two Jets Much Too Close Together". Comments/elipsis in [brackets] are my summations or deletions from the original.

"Two American Airlines jets were guided past each other at a fraction of the minimum legal distance of separation between them because of an error by an air traffic assistant, the National Transportation Safety Board said yesterday. [This happened late last month.]

"But Mr. Engen [chief of the F.A.A.] said he did not believe that the incident justified any permanent reduction of, or special restraints on, Chicago area traffic. He said the F.A.A. had determined that existing procedures, "when properly applied, do maintain a safe level of operation in the Chicago area." [...]

"According to officials of the safety board and the F.A.A., here is what happened:

"An air traffic assistant in the tower at Chicago's O'Hare Internation Airport assigned the wrong code to the crew of a United Airlines plane that was about to take off. The code was the one for an American Airlines plane that took off three minutes later.

"Result: Confusion

"The result was that the full-fledged controller whose job it was to radio subsequent air traffic instructions to the two planes saw the United plane on his radar scope with the American plane's identification, altitude and other data. The computer feeding this data to the radar scope rejected duplicate data for the American plane, rightly concluding that two planes could not have the same code. The American plan showed up only as a bright radar blip, without any identification alongside.

"Now, the controller wanted the United plane, with the American plane's data next to it, to climb to a new altitude. When he radioed instructions to "American 637" to climb, the United crew ignored them, and the instruction were carried out by the real American 637. [This caused American 637 to pass another American plane at 1/4 mile horizonal and 500 feet vertical separation -- the rules call for 3 miles and 1000 feet.]

"[The quick fix is to add more supervisory staff to the O'Hare tower.]

The biggest question in my mind is why does the system just drop one plane if it sees two with the same id? Shouldn't bells ring and lights flash when an obvious operator-error situation like this pops up? Also, why isn't the plane id part of the info sent by the on-board transponder? Aren't these id's simply the flight numbers assigned by the airlines? Why should it require any manual intervention to assign an id to a blip?

Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016

------------------------------

Date: Fri 12 Jun 87 07:27:29-PDT From: Peter G. Neumann <Neumann@CSL.SRI.COM> Subject: National Crime Information Center access To: RISKS@CSL.SRI.COM

Also in the NYTimes on the same day as the bombs, the sharks, and the enlightning rockets was a front-page item on a proposed expansion of the NCIC database that would permit Federal, state, and local law-enforcement agencies to exchange information on people who are suspected of a crime but have not been charged. A government advisory panel also recommended that the NCIC should have access to other databases such as those of the Securities and Exchange Commission, the Internal Revenue Service, the Immigration and Naturalization Service, Social Security, and State Department passport office. Attempts to legislate controls were also noted in the Times article, although concerns for protection of privacy seemed not to be commensurate with inadequacies in the technology and practice of protecting systems and networks from internal and external misuse. PGN

------------------------------

Date: 8 Jun 87 20:46:10 GMT To: mcnc!comp-risks@rti.rti.org From: condyles@talos.UUCP (Nick Condyles) Subject: Yes, Virginia, There Are Software Problems Organization: Philip Morris Research Center, Richmond, VA

The following appeared in the Richmond Times-Dispatch June 8, 1987 Section B page 1. The article pertains to the state of Virginia's attempt to automate distribution of child support payments.

STATE PAYMENTS FOR SOFTWARE SYSTEM HALTED

State officials have halted payments on a problem-plagued computer software system used in distributing child support checks and say the manufacturer will get no more money until the system works.

The state secretary of human resources, Eva S. Teig, said Saturday that the state has paid Unisys Inc. only $75,000 of the $395,000 total "because we are not satisfied with the product. Until we are satisfied, we will not continue payments on the program."

Ms. Teig's announcement came as she prepared to submit a confidential report on the child-support automation problems to Gov. Gerald L. Baliles. The report "is a look at what has happened and a recommendation on where I think we should be going," she said.

The software system has been blamed for massive snarls in the distribution of child support checks.

If state officials are unable to work out the problems, Ms. Teig said, "we'll look at other alternatives. We're committed to making it work."

Del. Howard E. Copeland, D-Norfolk, last month asked Attorney General Mary Sue Terry to investigate the state Department of Social Services' purchase of the software and determine whether it has been acquired through legal procedures.

Bert Rohrer, a spokesman for the attorney general, refused to comment on whether an inquiry is being conducted.

The purchase of the software was part of the department's attempt to take over collection of child support payments, a job that had been done by the courts. The centralization brought widespread complaints about lost checks, delayed payments and improper seizure of tax refunds.

Social Services Commissioner William L. Lukhard approved the purchase of the software system from Unisys, formerly Sperry Corp., in May 1985. Critics say the software never worked properly, causing further delays in the already slow distribution of checks.

A federal audit last month said operating the new computer system would cost Virginia up to $7 million per year, more than three times the amount originally anticipated.

Representatives of Unisys and state computer experts are analyzing the system to determine if it can be corrected and "some progress has been made," Ms. Teig said.

The state is prepared to take further action if the software cannot be salvaged, Ms. Teig said. She would not elaborate.

Several state legislators have suggested that Lukhard be replaced as social services commissioner.

"As I've said before, I think the best thing for the whole department is someone who would come in with a new broom and sweep clean," said Del. Frank D. Hargrove, R-Hanover. "The buck stops at the boss's desk."

Others defended the agency chief. "I would be disappointed and upset if he was driven out of office," said Sen. Joseph V. Gartlan Jr., D-Fairfax. "I regard him as one of the best administrators in state government."

Nick Condyles

------------------------------

Date: Tue, 9 Jun 87 17:42:20 PDT From: Date: 09 Jun 87 13:58:02 PDT (Tue)

Regarding your Contributions from the Editor in SEN on Heisenbugs (RISKS and SEN v12, n 2, Apr. 1987):

I felt I should bring to your attention the major problems in the area of concurrent or parallel computing. I am concerned because too many people are using the buzzword of "parallel computing" without fully understanding the consequences (not just in the supercomputing disciplines).

Many people are making vast assumptions on the synchrony and determinism of such systems and on the ability of new compilers to utilize vector and parallel processing. I wish to point this problem out because as parallel architectures move into the work space, these problems will increase and they are moving into areas such as SDI which have serious consequences.

One sub-problem I have noticed in debugging parallel codes is that many of the existing software engineering tools and methodologies are very sequentially oriented. I have noted sequential version numbering of certain file systems (manufacturers will not be mentioned) are great hinderances in working in highly parallel environments.

The problem of Heisenbugs is not entirely new in this realm, and I would like to point out significant technical report released some time ago on the problem:

%A Dale H. Grit %A James R. McGraw %T Programming Divide and Conquer on a Multiprocessor %R UCRL-88710 %I Lawrence Livermore National Laboratory %C Livermore, CA %D May 1983 %X Test programming the Denelcor HEP using HEP asynchronous FORTRAN. Has interesting insights to MIMD programming of the future.

This paper does have other antecedents (such as the Computing Surveys article by Anita Jones on multiprocessor experiences [1980]), but the above paper points out an attempt at debugging a program which completely interfered with (improved) the functioning of a buggy program. Languages like Ada(tm) cannot be expected to completely solve these problems, nor can their support environments, since these problems are still in the realm of open research issues.

Heisenbugs won't be restricted to parallel programs. Non-deterministic, self-modifying artificial intelligence programs also have the potential have showing these behaviors.

--eugene miya NASA Ames Research Center eugene@ames-aurora.ARPA "You trust the `reply' command with all those different mailers out there?" {hplabs,hao,ihnp4,decwrl,allegra,tektronix,menlo70}!ames!aurora!eugene

Additionally, I add the file I have on the risks of supercomputers:

Perspective: Supercomputer is just a marketing term -- Enrico Clementi (IBM)

Definition: A supercomputer is typically defined as the fast computer at a given point in time. Another definition is any computer which turns a CPU-bound problem into an I/O-bound problem. {Ken Batcher}

Risks of supercomputing

1) User bites off more computation than can chew: 27 hours weather for 24 hour forecast. Supercomputers and parallel processors are O(n) solutions for O(n^3) problems in some cases. Danger of the space filled by the computation (take the space or what ever). It is also known, now, that the NWS can be liable for weather forecasts.

2) Lack of software and the fact it is state of the art hardware (tends to be not as well shaken out) not necessary fault-tolerant (PEPE [a BMD computer] might have been an exception). The typical supercomputer application tends to be behind the software engineering art.

3) A perceptual power trip problem: most powerful thing we have can handle ANYTHING. Stop thinking and do more computing.

4) Normal risks inherent in all computer analysis and simulation: bad data, incorrect models, only faster, and in some cases harder to detect errors.

5) Many of the newest designs are using radically different architectures: hypercubes, ensembles like the Connection machine, shared memory systems, hardware semiphores like the HEP, data flow machines, ELI (or VLIW) machines, vector processors and so forth. Programming applications for these machines has been described as programming in 1946. A comment ascribed to Steve Squires of DARPA attributed that perhaps only 20% of programmers out there could make the transition to working on these new machines. It's not just loop or recursion problems, consider staravation and deadlock in applications programs. People waiting for smart compilers better not hold their breath. You should remain skeptical of any claim of sophistication (i.e., drop your dusty deck in this machine).

A problem I have: tools designed for sequential programming environments are difficult to use in parallel environments. The VMS/RSX version numbering system is a real pain because it has a serial numbering. This is a bottleneck for some of my programs.

Lastly: n) The physical embodiment problem (Ken Thompson): harm by dropping out of a plane. (A mention of this problems with the Belle chess machine: a specialied architecture, but not a super).

------------------------------

End of RISKS-FORUM Digest ************************ -------