Someone answered mail from RISKS, sending directly to RISKS-LIST@KL.SRI.COM! Someone else answered that. It turns out that my macros failed to complete properly, and consequently a window of vulnerability that permits direct rebroadcast (because of a TOPS-20 glitch in handling very large lists) remained open. I have tried very hard to keep this window narrow, and all other attempts get indirected to me personally — so I know if anyone is trying to hit the window. I've been lucky — since August 1985, someone hit the direct rebroadcast only once before. And I have not advertisedd the fact that you should not mail to RISKS-LIST, because I thought that might invite some nastiness from people who resent moderation. (Remember, extremism in the nondefense of moderation is not a virtue.) But very soon RISKS will move to another system, and that window of vulnerability will go away — only to be replaced by new windows. So, at any rate, apologies for the confusion, thanks to those of you who sent me mail on the subject. Soon we may be onward to lower-risk RISKS.
I believe the explanation of the recent crash of a Swedish fighter prototype may be less interesting than the last article implied. The pilot was flying the Gripen for his first time, and held the nose too high upon landing. The result was exactly as described before - a wobbly landing that caused a wingtip to hit the runway at about 80 mph. The plane was damaged and the pilot survived. Keep an eye on Aviation Week magazine for a full report. Dave Newkirk, att!ihlpm!dcn
In a short article in this week's Aviation Week, the following statements were made: Saab Blames Gripen Crash on Software The cause of the accident that destroyed the first prototype of the Swedish JAS-39 Gripen Multirole combat aircraft has been traced to a software problem, program officials said last week. The pilot, Saab-Scania Lars Radestrom, and the aircraft structure and subsystems have been cleared of fault based on data developed so far. "We consider the problem to be associated with the control software only," one official said. No addutional details were given.
According to a brief article in Aviation Week and Space Technology (February 27, 1989, page 31), the accident that destroyed the prototype of Sweden's JAS-39 Gripen multirole combat aircraft was caused by a software problem, according to program officials at Saab. The article doesn't go into any further detail, other than to say that Saab officials are working on a revision of the Gripen's flight test program to complete flight testing with the remaining four prototypes and still meet their delivery date, which seems extremely optimistic as it is doubtful they have already determined all the rework that will be required to fix the problems that caused the crash, including (it appears) the need for a lot more software QA.
Although I RISK becoming known as an "Aviation Week" funnel, the following letter to the editor (AW&ST January 30, 1989, pg. 88), quoted without permission, gives a pilot's account of a flight with a multi-engine failure, which I think may be of interest to RISKS readers: Listening to the news reports on the tragic British Midland crash in the U.K., I was struck by the seemingly unanimous conclusions of the aviation gurus concerning the near impossibility of a two-engine failure of the Boeing 737 using the CMF56 engines. If the odds on that are improbable, then the flight I had June 14, 1983, was even more so. I was flying as captain for Transamerica Airlines on a DC-8/73, newly reengined with the Snecma/GE CMF56s, and had three engines fail on me simultaneously during a military passenger flight from Kadena AB, Okinawa, to Clark AB in the Philippines. I was able to airstart the engines during descent and made a successful landing at Clark. Upon taxi-in the engines again failed, and the fourth engine failed as I was parking. It was later determined that the probable cause was the specific gravity adjustment on the main engine fuel control/MEC was set improperly for the JP 4 fuel being used. My experience certainly shows that aircraft don't listen to the odds of probability and that, unfortunately, Murphy's Law is always operative. Don Orlando, Concord, CA I'm surprised they wouldn't shut down the engines immediately after landing, rather than trying to taxi in, as a precaution, but I have no portfolio in these matters. Karl Lehenbauer
This is for all you probabilitists (no, it's probably not a word) out there counting engines on aircraft everytime you get on board.....give it up!!!! from Aviation Week And Space Techlonlgy : Feb 20, 1989 issue pg 13. quoted without consent and not for profit...so sue me for nothin'. "BIRD STIKES CONTINUE to be a cause of aviation accidents worldwide... ...Ethopian Airlines experienced some of the most trouble last year. In September, an Ethopian Boeing 737 crash killed 31 people after the aircraft hit birds and damaged both engines during a takeoff from Bahar Dar, Ethopia. Earlier in the year an eagle penetrated the cockpit of an Ethopian 727, breaking the copilot's leg and damaging flight controls. The aircraft made a safe emergency landing in Khartoum, Sudan." Conclusion : probability burdens our society(ies) needlessly. I'll PROBABLY burn in hell for saying that.
Yet another ATM risk...in preparation for a brief holiday in Los Angeles, I elected to change a modest amount of money ahead of time, and use ATMs for more money as I needed it. The U.S. immigration people didn't like this, and I came very close to having to scrap my holiday. They insist that visitors be able to prove that they can support themselves while in the U.S. (a reasonable requirement), and my bank card wasn't adequate proof (to them) that I could. They grudgingly let me in to the U.S. after asking pointed questions about who I was staying with, who she worked for and how much she made. They flatly insisted that my card meant nothing to them, even when I offered to go to the nearest ATM (50m away), do a balance inquiry and show them the results. I could understand them being concerned about me losing my card (a Risk in its own right). But that wasn't what was bothering them...they were bothered by somebody supporting herself with technology whose implications they obviously didn't appreciate. - laura
The 15 Feb 89 issue of _DATAMATION_ has an article titled "Is Error-Free Software Achievable?" which praises the Space Shuttle software. (The article would have one believe that the computing systems on the Space Shuttle, both hardware and software, are entirely to be credited to IBM. How does Big Blue always get errors like this to come out in their favor?) The article quotes Anthony J. Macina of IBM-Houston: "The development of error-free software for these complex real-time systems [national defense, reactor control, air traffic control, and manned space flight] is within the reach of current software development technology." At the beginning of the article that is simplified to: Is Error-Free Software Achievable? The answer is yes, says prime NASA contract developer, IBM. And while $1000 per line of code is prohibitively high for the average IS shop, some valuable lessons can be learned. Despite this the article says that the 500,000 lines of source code "achieved an "exemplary" error rate of .1 errors per thousand lines of code detected after release." While that is certainly better than usual code, calling the code "error free", when their own data indicate fifty errors, is an interesting metric for quality control! Bob Wilson, Ford Aerospace Corp., San Jose, CA
Last Sunday's (2/26) comics page had two strips devoted to computer viruses: "Dick Tracy" and "On The Fast Track". One fairly serious about a defense contractor's (Diet Smith) computer, the other humorous about the virus turning all users into clones of the programming manager (Bud Spore). Is comics page where most of the population will get most of its information about viruses?
Yes, the network is going to hell — or sinking slowly into the muck. We (BRL) have have been beating on DCA and BBN as we identify particular problems. Only a few other sites/individuals have noticed (and recognised the underlying problems) as near as I can tell. I won't go into details unless you ask for them, but the net result [oof!] is a severe case of routing instability. Networks will come and go at random intervals. We have also seen some breakdown in the Domain Name System as a result of this; which only compounds the difficulty. As for the specific failure you noted with respect to BRL, our aliases (mail-ID to mailbox mapping) file got trashed late last week. The first 160 or so aliases got deleted. The "postmaster" address also got trashed which was most disconcerting (made it a real bear to tell us about the troubles too!.....)
Please report problems with the web pages to the maintainer