RISKS-LIST: RISKS-FORUM Digest Sunday 22 January 1989 Volume 8 : Issue 13 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Gigabit superhighway/worms (Vint Cerf) IAB Ethics DRAFT (Vint Cerf) Space shuttle computer problems, 1981--1985 (Jon Jacky) F-16 that can't stall falls from sky (Scot E Wilcoxon) Re: China accused of software piracy (Jim Olsen) Losing systems (Dale Worley, Chris Lewis) Re: Structured Programming (John Mainwaring, Mark Rosenstein, Steve Pozgaj) ---------------------------------------------------------------------- Date: 23 Jan 1989 00:09-EST From: CERF@A.ISI.EDU Subject: Gigabit superhighway/worms (RISKS-8.9) In RISKS-8.9, Brad Blumenthal asks whether our legislators and their staff are aware of the similarity between the internet and the proposed multi-gigabit superhighway. I can assure Mr. Blumenthal that the question has arisen and has been posed to several members of the research community by members of the Congress responsible for scientific and technical matters. The worm affair made a strong impact on policy makers. Vint Cerf ------------------------------ Date: 23 Jan 1989 00:09-EST From: CERF@A.ISI.EDU Subject: IAB Ethics DRAFT (RISKS-8.8) The copy of the IAB statement on ETHICS was a DRAFT copy circulated for internal comment by the IAB before final editing and release. I would be very interested to know how a copy happened to fall into Mr. Stoll's hands. Readers should be advised that the copy they saw is still subject to change until ratified by the IAB. Vint Cerf [By the way, subsequent to the appearance of RISKS-8.8, Cliff noted to me that he had accidentally omitted the author's name from the DRAFT. PGN] ------------------------------ Date: 20 Jan 1989 15:27:13 EST From: jon@june.cs.washington.edu Subject: Space shuttle computer problems, 1981--1985 Here are excerpts from an article that appeared a week before the flight of the space shuttle Discovery last September: NASA's close calls: lessons learned? by Richard Doherty, ELECTRONICS ENGINEERING TIMES, September 6, 1988, pps. 4,8. ... The House Science and Technology committee convened its own investigation of the (January 1986 Challenger accident) just days after the Rogers commission concluded its four-month effort. (Its findings are reported in) `Investigation of the Challenger Accident, House Report 99-1016'. That report indicates ... dozens of failures in the shuttle's General Purpose Computer (GPC) and Avionics systems. ... NASA has reviewed these flight anomalies and decided that they fit within the acceptable risk criteria. Thus, it has not made any significant changes to system hardware or software for Discovery's launch. ... Most engineers tracking the shuttle program can recall very few reported avionics and computer-system failures during the program's 24 completed missions. Nevertheless, more than 700 anomalies involving computers and avionics have been logged by NASA. ... [Here follow just a few of many examples from the EE TIMES article. Most seem to involve hardware or sensor failures. Several examples in the article are not computer- or even avionics-related. ] STS-6, April 4, 1983: ... Landing gear must be manually deployed after computer fails to trigger its descent. STS-9, November 28, 1983: Four hours before re-entry, pilot orients orbiter using RCS (Reaction Control System) steering jets. After jets fire, one computer crashes. A few minutes later, a second goes down [ There are four redundant GPC computers running identical software plus a fifth GPC running different backup software - JJ]. Pilot John Young delays landing while craft drifts in space. Then one of three Inertial Measurement Units fails. (Young testified three years later: `Had we then activated the Backup Flight Software, loss of vehicle and crew would have resulted.' He now says problems have been resolved. Post-flight analysis shows each GPC failed when RCS jet motion jarred a piece of solder, shorting CPU boards). Before landing, the second of three APU's (Auxilliary Power Units) fails. Fire and explosion occurs while orbiter is parked at its landing site. ... NASA engineers label this incident a `double-failure scenario that just beat all the probability odds.' ... STS-19 (51-F) July 29, 1985: Three minutes into ascent, a failure in one of two thermocouples directs computer shutdown of center engine. Two minutes later, engine chamber pressure is indicated as zero. Mission control decides to Abort to Orbit. ... Challenger is in orbit 70 miles up, 50 miles lower than planned. Had shutdown occured a half-minute earlier, mission would have had to abort over the Atlantic. (NASA has reset some of the binary thermocouple limits via software changes). STS-13 (41-G), November 5, 1984: ... Landing gear must be manually deployed after computer fails to trigger its descent. - Jonathan Jacky, University of Washington ------------------------------ Date: Fri, 20 Jan 89 17:07:16 CST From: sewilco@datapg.MN.ORG (Scot E Wilcoxon) Subject: F-16 that can't stall falls from sky Reprinted with permission from the Tampa Tribune, 23 December 1988, Page 1B Crash of F-16 still unexplained by MacDill staff By STEVE HUETTEL, Tribune Staff Writer TAMPA - Moments after an instructor warned 1st Lt. David S. Johnson that he might be flying too slowly, the student pilot's F-16 fighter stalled and plummeted into the Gulf of Mexico. Johnson ejected safely Sept. 9 and was back in the cockpit within a month. A month before he is due to graduate, MacDill Air Force Base officials still won't say whether the 24-year-old pilot was negligent or if an onboard computer designed to keep the $9.5 million jet from stalling failed. But, crashing an F-16 isn't necessarily grounds for dismissal from the six-month course, they say. "It's an environment where they're still learning the airplane, and mistakes can happen," said Capt. Dian Lawhon, a MacDill spokeswoman. "At that point, they might not have acquired some of the skills they need." Students can be yanked at any time, she said, for "gross pilot error." Word that Johnson's jet stalled surprised the F-16's manufacturer and former pilots familiar with the fighter. A computer inside the fighter should override any commands that would cause a stall, said Joe Thornton, a spokesman for General Dynamics in Fort Worth, Texas. "If a pilot tells the airplane to do anything the airplane doesn't want to do, the computer will take control of the airplane from the pilot," he said. "The pilots I talked to said you can't (stall) it." But the computer is programmed only for common, dangerous flight configurations, said 1st Lt. Susan Brown, a MacDill spokeswoman. "It's not set up for every possible way you can get yourself into trouble," she said. Johnson, of Parker, Colo., did not return telephone calls to comment on the accident. On the morning of Sept. 9, he was practicing fighter maneuvers with an instructor in a second plane over the Gulf west of Fort Myers. It was Johnson's seventh solo flight in the F-16. He had flown more than 200 missions in trainer aircraft, earning outstanding evaluations from his teachers at basic flight and fighter preparation schools. Four times, the pilots flew a downward corkscrew maneuver in which Johnson tried to get behind the other aircraft to line up a gun or missile shot. Something went wrong as they broke off the exercise the last time. The Air Force won't release an investigation board's findings or statements by the pilots. But a heavily censored version of the report obtained under the federal Freedom of Information Act states that Johnson's F-16 stalled after he finished the last maneuver. A drawing of the maneuver doesn't show Johnson's speed or altitude. The instructor pilot he trailed started at more than 400 mph but slowed to 150 mph as he climbed to 14,700 feet at the end of the exercise. "We got a little slow there, check your air speed," the instructor warned in a transcript of his radio conversation with Johnson. The student acknowledged the message, then disappeared from the instructor's sight. The F-16 can stall at speeds of 230 mph or slower, depending on its weight and angle of flight, MacDill officials said. They declined to say what speed Johnson was flying when his plane stalled or the altitude at which he ejected. The report drawing depicts Johnson's jet in a near-vertical climb just before it stalled. "That should never have happened," said Howard Acosta, a former Navy pilot and St. Petersburg attorney who successfully sued General Dynamics on behalf of an F-16 pilot's widow last year. "The computer should change the angle of attack and get the wing flying again." Unlike older aircraft, the F-16 has a fly-by-wire system that controls the flaps and engines through electrical impulses. The pilot's commands go through a computer that prevents the aircraft from getting into situations where it could stall or break apart from excessive gravity forces, say pilots. "It's designed not to stall," said a former F-16 pilot. "It's made to recover. You can take your hands off, and it'll fly." Scot E. Wilcoxon sewilco@DataPg.MN.ORG {amdahl|hpda}!bungia!datapg!sewilco Data Progress UNIX masts & rigging +1 612-825-2607 uunet!datapg!sewilco ------------------------------ Date: Sun, 22 Jan 89 13:50:51 EDT From: olsen@XN.LL.MIT.EDU (Jim Olsen) Subject: Re: China accused of software piracy Organization: MIT Lincoln Laboratory, Lexington, MA >American companies are losing "many millions" of dollars in potential >business in China because the companies' computer software has been >widely pirated... China has no copyright law of its own... This is an example of the risk in assuming that the laws of one's own country apply (or ought to apply) everywhere. Copyright and patent protection are, fundamentally, matters of internal law for each country. Foreign copyrights exist only via international copyright convention. In a nation which is not signatory to a copyright convention, foreign copyright is invalid. However, authors in such a nation receive no international copyright protection. Each nation decides if such a tradeoff is in its best interests. Thus, copying American computer programs in China is perfectly legal, and therefore does not deserve the term 'piracy'. American law does not apply in China, even if some American companies would like it to. ------------------------------ Date: Fri, 20 Jan 89 11:27:40 EST From: worley@compass.UUCP (Dale Worley) Subject: Losing systems Jerome Saltzer remarks that the domains of application of computers have been enlarging at an enormous rate. The rate at which computers become cheaper relative to number of them sold (the "experience curve") is no different from any other product. What is different about computers is the extraordinary price-sensitivity of potentially computerizable applications - a tiny drop in the price of computers introduces whole new application domains. This puts the computer industry into a rapid positive feedback loop of dropping prices, widening applications, and increasing unit sales. I also agree with his remarks on how to manage computer-based projects, but you must remember that one result of these policies is that one will get somewhat less bang for the buck than the state of the art would tempt one to expect. As far as managers are concerned, I'm reminded of a comment by Lester Thorow, dean of the MIT School of Management, regarding their new "managing technology" degree program: Many managers want to learn how to manage technology, but few want to learn about technology. Certainly, American managers have little technical training, and few (especially in the upper echelons) want to acquire any. This has been blamed for the inability of American companies to deal with rapidly changing technology. In contrast, German and Japanese managers often have technical training and are reputed to be better at dealing with changing technology. Do they have a lower rate of computer project failure? Dale Worley, Compass, Inc. compass!worley@think.com ------------------------------ Date: 20 Jan 89 20:12:09 EST (Fri) From: clewis%ecicrl%gate%tmsoft@csri.toronto.edu (Chris Lewis) Subject: Re: Losing systems.... In Risks 8.6, Vince Manis postulates a number of hypothesis over how "megabuck systems ... go into the trashcan" after seeing reports of two such in Risks 8.4. I can add another reason with an example (actually a "near failure"): A Government creates the system by executive edict, without any technical study. Especially those in non-technical areas where the problem isn't well understood. Which I expect is the actual reason for the failure of the first example in risks 8.4. The second example in Risks 8.4 is probably simply that there was *no* design control. In projects where there are multiple "customers", it is extremely important to have firm control vested in *one* person or small group of people. If you have dozens of people yammering for this feature or that, and nobody can or will say "no" to some of them, you're in *deep* trouble. The report on this system implied that this was one of the main reasons for failure. Which is also why some language standards are so big.... My example: The current incarnation of the Ontario Health Insurance Plan (Government run health insurance system, OHIP for short) was created by Government legislation (Ontario Health Insurance Act, 1972 - I think), to be in operation approximately 6 months later. At the time, the Ministry of Health didn't have much of a DP dept., nor had there been *any* technical study. When I studied this system for a Royal Commission back in '79, I can't help remembering how awestruck I was that they actually had the monster in operation at 6 months. Startup from zero staff, resource or facilities. Awesome. They then paid for it with two or three years of continuous firefighting. The only reason that they succeeded was that they had lucked into some of the best DP people/managers I've *ever* met. As well as some of the worst senior administrative people I've ever had the misfortune to meet. This application is still probably the biggest single DP application in the entire province - 13 master files (one of which was 70 reels of 6250 BPI tape back in '79), oh about 12 main programs and had to be run on a 48 hour cycle. It took somewhere near 24 hours to run on their machine as of '77: 370/168 I believe. The head analyst gave me a report discussing a lot of this, including the comment "systems usually are obsolete and need to be replaced within 3-5 years - this one has already outlived it's lifespan by 5". Last I heard, they're still running effectively the same stuff.... (10 years later) Chris Lewis, Elegant Communications Inc., Markham, Ontario, Canada, {uunet!attcan, utzoo}!lsuc!{gate!eci386, ecicrl}!clewis ------------------------------ Date: 20 Jan 89 16:16:00 EST From: John (J.G.) Mainwaring Subject: re: Structured Programming In the replies to Karsh's article published to date, several interesting points were made, but one clear statement of objective was missing. The methods which have come to be known as structured programming were intended to avoid the use of what were then recognized as error prone contructs. This is in the spirit of analyzing aircraft accidents and changing instrument or control designs which pilots tended to misunderstand or misuse. There may well be those who have lost track of the idea that the structuring of a program should break the job down into segments which are small enough to understand, and eliminate hidden interactions between segments which make it difficult to understand how they fit together. It is possible to indent beautifully, avoid gotos, keep modules under a page, and use data structures that make it totally impossible to understand how it all fits together. The larger the system, the greater the difficulty of creating an overall design and ensuring that the parts really fit together in an understandable way, ie that a structure really exists at ALL levels. Does anyone know of recent studies based on current languages used in nominally structured fashion of what errors are most common and what disciplines seem most likely to avoid them? Such articles used to be common at one time. Perhaps now would be a good time for a few more, preferably in some of the popular as opposed to academic magazines. The converted may enjoy a good sermon, but it has the chance to do more good when it reaches a wider audience. My views are probably my own but only coincidentally those of my employer or anyone else. ------------------------------ Date: Sat, 21 Jan 89 08:27 CST From: Mark Rosenstein Subject: Structured Programming, Object Oriented Programming: A quote Organization: MCC, 3500 West Balcones Center Dr., Austin, TX 78759 David A. Moon from the foreword to "Object-Oriented Programming in Common Lisp" by Sonya E. Keene [an interesting book, by the way]: The nature of object-oriented programming is such that it is most beneficial for large programs that are written by multiple authors and are expected to last a long time. The ease of implemententing a small, simple program does not much depend on what programming methodology is employed, and one who has dealt only with small programs may not see any point to the object-oriented discipline. However, anyone who has been through the design, development, documentation, testing, and maintenance of a large software system in a non-object-oriented fashion, and then has experienced the same process in an object-oriented system, will understand why there is so much interest in object-oriented programming. It isn't magic, but it is a good technique for organizing large software systems and making them comprehensible. I believe the above is also exactly true with respect to structured programming. Mark. ------------------------------ Date: Fri, 20 Jan 89 08:55:40 EST From: ames!uunet!dmnhack!dmnboss!steve%pasteur.Berkeley.EDU@ucbvax.Berkeley.EDU (Steve Pozgaj) Subject: Specious Arguments and Structured Programming I have always enjoyed controversial debate, *but*, there is a major difference between controversial debate and provocation. I must say that I find Bruce Karsh's posting in RISKS 8.8 simple provocation. It is the kind of statement that forces a "bite your tongue and count to 10" reaction. Why? Provocation can only lead to "heat" in arguments, not "light". In this regard, I agree wholeheartedly with Jim Horning's subsequent reply that we'd all be better off, if we're to discuss structured programming, having a discussion based on "light" issues, not "heat" issues. You know, I'd bet Karsh had his tongue just about puncturing his cheek when he wrote his piece. Surely he can't have been serious? Either that or he's never produced code bigger than a student programming assignment. (Wonder how it passed with all those left-margin aligned GOTO's?-) In the real world of programming, systems are often very complex, as well as complicated. To not bring a disciplined attitude to their construction is suicide. I learned structured programming at University, from people such as Jim Horning. It is one of many disciplines. It works, as do others. In my opinion, it works better ... but, maybe, not for everybody. However, I cannot imagine program construction without *some* discipline. In any case, I view Karsh's provocation as one of "form", not "substance". He argues [very speciously] about indenting, variable naming, and other "rules" which all pertain only to form. This is like attacking literature based on rules of grammar (e.g. saying that only "free form" prose is valid poetry and that rhyming couplets produce garbage). Why waste the time? Any conclusion can be drawn from incorrect premises, which is exactly what Karsh does. By stating that SP isn't about correctness, but about maintainability, he goes on to draw all sorts of silly conjectures. So what? [...] ------------------------------ End of RISKS-FORUM Digest 8.13 ************************ -------