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…
Phone lines - including the 911 emergency number - were dead throughout San
Luis Obispo [California] for thirty minutes Tuesday night [Oct 9, 1990].
The interruption, which affected 30,000 customers, occurred at 10:15 p.m.
and affected virtually all phone lines in the city, said Jim Bower, Pacific
Bell's Central Coast area manager.
Bower said the interruption was caused by a computer programming error made
by a Pacific Bell employee. "We were putting in a new program and an error was
made," he said. "We were responsible for the error and corrected it as soon as
we could."
The error also caused phone lines at the Sheriff's department,
including the 911 number, to go dead for 30 minutes, said Sheriff's Sgt. Scott
Thompson. The disruption didn't cause any serious problems, he said.
- San Luis Obispo Telegram Tribune, Oct. 10, 1990, p. A-5
John Dudeck, jdudeck@Polyslo.CalPoly.Edu ESL: 62013975 Tel: 805-545-9549
Our organization has been playing the game of Phone Tag a lot recently. We
reasoned that, if the other player could leave a voice message for us instead
of asking a receptionist to have us call them back, we would win the game more
often. (Not to mention improve our response to our customers.) Accordingly,
we installed telephone answering machines for several people, including myself,
on the desks next to the telephones. The telephones are just the visible part
of the campus' fancy private branch exchange (PBX).
The PBX was insulted when I installed my machine. Accordingly, when one of our
secretaries tried to call me, it rang my phone only two times while it rang in
the callers ear four times, then "forwarded on no answer." When the secretary
answered her phone, she was talking to herself.
So I told my machine to answer on two rings. Then I found out that my machine
has a bad attitude.
For two days it left me "1 message waiting" but there was nothing on the tape.
I discovered that it had been telling people to leave their name, company and
phone, then hanging up on them. This was because I had mistakenly moved the
wrong one of two identical switches on the side to fix the earlier problem.
Today I caught my machine cheating at Phone Tag.
I started the game by making a call to a person in our Inventory Department.
The line was busy, so I tagged her by instructing our telephone system to call
me back when she hung up. YOU'RE IT.
A few minutes later I left my desk on a short errand. And while I was gone,
she hung up and my phone rang. But now my machine saw its opportunity! It
answered the call, apologized to her for my absence and instructed her to leave
her name, company and phone. YOU'RE IT.
The message I received on the machine made it clear that this was breaking the
rules of the game.
* * *
Fortunately, this last event never actually happened. I realized the risk I
was taking due to the interaction of two Phone Tag technologies just before I
left my office. A colleague and I simply tested and verified the correctness
of my scenario.
Ed
Summary of story by AP Science Writer Lee Siegel ``Wrong Computer Instructions Were Given to Discovery Before Liftoff''. According to Discovery flight director Milt Heflin, the shuttle was launched with incorrect instructions on how to operate some of its programs. The error was discovered by the shuttle crew about one hour into the mission, and was quickly corrected. NASA claims that automatic safeguards would have prevent any ill effects even if the crew had not noticed the error on a display. The error was made before the launch and discovered when the crew was switching the shuttle computers from launch to orbital operations. The switching procedure involves shutting down computers 3 and 5, while computers 1 and 2 carry on normal operations, and computer 4 monitors the shuttle's ``vital signs'' [I'm just following the article on this, I don't know whether it is accurate]. However, the crew noticed that the instructions for computer 4 were in fact those intended for computer 2. Heflin stated that the problem is considered serious because the ground pre-launch procedures failed to catch it. Fernando Pereira, 2D-447, AT&T Bell Laboratories, 600 Mountain Ave, Murray Hill, NJ 07974 pereira@research.att.com
A few months ago, I told a friend about the various stories I had read here and elsewhere about the A320. The subject came up when I explained why I would never again fly Northwest Airlines (they bought a bunch of A320s for domestic use). He just recently sent me this mail: <> From: RIch EPstein <@VM.CC.PURDUE.EDU:REPSTEIN@GWUVM> <> To: Spaf <spaf> <> Date: Tue, 09 Oct 90 16:13:44 EDT <> <> I just came back from the IEEE Visual Languages WOrkshop, which <> I thoroughly enjoyed. However, I thought you would find my <> air horror story of interest: <> <> The conference was in Skokie, ILL, so I had to fly in and out <> of O'Hare. We had a slight mishap on the plane on the way back <> to Dulles. Heavy rains leaked into the plane and knocked out <> the transponders and the auto-pilot computer. About 15 minutes <> into the flight the pilot announced that we had to return to <> O'Hare because the air traffic controllers couldn't "pick us <> up". In other words, we were invisible, in the clouds, at <> O'Hare. According to an Air Force ROTC student here at GW <> the pilot meant this literally. Radar picks up aircraft by <> means of the signal sent out by the transponders. <> <> We flew around in the clouds for 15 more minutes. We landed <> with all sorts of emergency vehicles on the runway. Then we <> waited for almost three hours until they finally replaced <> the transponders and computer and we left Chicago on the <> same plane (which I didn't like too much). <> <> The pilot got on the p.a. system after we were successfully <> on our way to Dulles and he made an interesting remark. He <> said that this was a good plane because it had "stainless <> steel aeronautical control cables", a reference to the fact <> that an Airbus would probably have been disabled completely <> in a similar circumstance. I have no doubt that the pilot <> was referring to the Airbus when he made this remark. I wrote asking his permission to send this on to Risks, and in his reply, he said: <> By the way, I think the ground crew at O'Hare might have been <> negligent in my airline incident. When we entered the airplane <> water was LITERALLY POURING INTO THE AIRCRAFT at the door to <> the airplane. Passengers had to JUMP THROUGH a sheet of water, <> a thin veil, maybe 1/4" thick, but continuous. The water was <> coming in from the top of the door and onto the floor of <> the airplane. Obviously, the water went from there into the <> underbelly of the craft. The reason for this was that the <> airport walkway was not meeting the fuselage correctly.
Just to signal another minor problem similar to that of truncation to 80
columns: After several unsuccessful attempts to follow the masthead
instructions for FTPing RISKS issues, I discovered this morning that my IBM3278
emulator eats square brackets. CRVAX runs VMS, I guess, but I hadn't used such
a system for years: only when I moved my attempts to a Unix machine did I
realize why I could not cd to the risks directory.
The 3278 keyboards don't have square brackets, but square brackets entered
through an emulator are stored as escape sequences. ASCII square brackets that
exist in mailed of FTPed files are stored as such, and displayed as blank
spaces.
and here are a few left square brackets embedded in a series of dashes:
--------------------
and a few right brackets:
----------:::::----------
Amazing... I thought this was worth signalling in case you receive requests
for help from other IBM users.
Lorenzo
Lorenzo Strigini, IEI del CNR, Via Santa Maria 46 I-56126 Pisa ITALY
Tel: +39-50-553159 ; Fax: +39-50-554342 ; strigini@icnucevm.bitnet
[Lorenzo and RISKSers, I have long been annoyed at the miserable
VAX command "cd sys$user2:[risks]" to get the anonymous FTPer into
the RISKS directory. In response to Lorenzo's message, SRI's CRVAX
wizard Ray Curiel, at Steve Milunovic's request, has provided a terse
alias: "cd risks:". Upper/lower case does not matter, but the colon
does. HooRAY! Thanks. I changed the masthead. Now you don't need
to escape from the colonease? PGN]
With all of the discussion on the risks of computerized and/or electronic
controls in Aircraft, one should not overlook the fact that there could be
more down to earth (pun intended) risks along the same lines.
One of our cars has a computer, and various other electronic sensors that
control the engine. A couple of years back, shortly after we bought the
car, it started intermittently losing power. Not too much trouble on city
streets, but on the freeway, it was downright dangerous.
The symptom was that the car's engine would drop to idle speed, and would not
speed up, not matter what we did with the gas pedal. It could be reset by
turning off, and restarting the engine.
We had brought the car in several times, but the dealership could not find
the problem.
Then came the fateful day...My wife was driving the car when the engine dropped
to idle at the merge of two freeways, and she was in slow lane of one freeway
that merged with the fast lane of the other...I was not happy when I got the
call (I told her to call the dealership to come get the car!).
Somehow she was talked into driving the car to the dealership, when the
same problem occured. This time, though, it occured in front of a truck
hauling an oversized load in the slow lane of the freeway. If there had not
been an offramp and a truck driver that was on his toes, we might be talking
about my wife in the past tense at this point.
The eventual problem was an intermittent failure of a sensor in the air intake
system. The computer responded by cutting down the fuel flow to its minimum
setting.
I just wonder how many of these types of problems exist out in the world, and
if anyone had been killed by them. All in all, everyone was very lucky...
This Time.
}... It's a FADEC failure" [FADEC = Full Authority Digital Engine Controller].
}... There has been a number of instances of spurious signals causing
}747-400 engines to throttle back or shut down, according to Flight ...
This begins to sound a bit like the discussion of electronic vs. mechanical
rail line switching controls.
I earned my Airframe & Powerplant mechanic's license (A&P) nearly 25 years
ago (when pilots were made of iron and planes were made of wood ... but I
digress (-: ). At that time, jet engine controls were almost entirely
mechanical, consisting of amazingly complex blocks of pneumatic and
hydraulic sensors and actuators. Each engine had a main controller and a
backup, "get you down alive" controller that provided just enough control
to keep the engine running if the main failed.
Has the concept of such backups been lost in the rush to computerize?
Jerry Hollombe, M.A., CDP, Citicorp, 3100 Ocean Park Blvd. Santa Monica, CA
90405 (213) 450-9111, x2483 {csun | philabs | psivax}!ttidca!hollombe
>The programme went on to consider the crash of the A320 at Bangalore. A pilot >was interviewed saying that it was virtually unknown for an aircraft to lose >height in such a way in clear conditions on a landing approach. We know that the Bangalore crash _was_ pilot error. Both the `back box' and the cockpit voice recorder indicate that the pilots were to blame. Flight International has given a good account of this, including the CVR transcript. The captain left the aircraft in idle descent mode and flew into the ground. The aircraft warned the pilots (both visually and aurally), but they ignored the warnings. Equinox chose not to report this (the rest of the programme seemed very convincing). A lot of people have a lot of axes to grind over Airbus Industrie, and receiving totally impartial and accurate information is almost impossible. Listen to Boeing and you hear that the A320 is a death-trap. Listen to Aerospatiale and you hear supreme confidence. Watch TV programmes and you see sensationalism. Ken Tindell, Computer Science Dept., York University YO1 5DD, UK Tel.: +44-904-433244 UUCP: ..!mcsun!ukc!minster!ken
>- The DFDR recording stops 4 seconds *prior* to impact with the trees. (Davis
> added that, in his entire career, he had *never* come across a similar
> instantaneous stoppage of a recorder.)
Is it possible that Davis is not familiar with *digital* flight recorders?
I've seen some commentary on such an issue in the aviation press recently:
the underlying problem is that some (all?) digital flight recorders buffer
incoming data in semiconductor memory, which loses its contents on power
failure. The airworthiness authorities are starting to be seriously
displeased with the potential for loss of crucial data, and there are
mutterings about requiring non-volatile memory.
I don't know for sure that this accounts for the above claim, but it
certainly sounds like the right sort of symptoms.
(Would a simple explanation like this go unconsidered? Quite possibly,
especially in the context of a media story whose basic slant is "dirty
work at the crossroads". As I've commented before, there is a problem
with the A320 business in that almost all participants have axes to
grind and it is very difficult to get a balanced view. The media are
not exempt from this, since sensation sells and boring truth doesn't.)
Henry Spencer at U of Toronto Zoology henry@zoo.toronto.edu utzoo!henry
The areas left to the implementer were left that way due to disagreements on the proper and useful choices. All such options must be fully specified in mandatory sections of the Ada reference manual. The general phrase I remember being used whenever such items were discussed is that the market will select among conforming compilers. In hindsight it might have been better to add some language clauses that allow you to specific or explicitly leave unspecified the tasking priority requirements. On the other hand many people believe that the ADA tasking model, while interesting, is not general enough to begin with.
> The author does not seem to realize the contradiction between the
> *reliability* and *portability* quoted as features of Ada on one hand, and
> the lack of definition of crucial features on the other.
There is no inherent contradiction here, unless "reliability" and "portability"
are taken to include the phrase "guaranteed or your money back". (Mind you,
some of the Ada enthusiasts essentially do claim this.) "Reliability" and
"portability" are not absolutes, especially in a language constrained to be
implemented efficiently on current machines. If such constraints mean that a
particular feature is not completely defined, this just means that
reliable/portable programs must avoid depending on it. This does require
competent programmers, however, and one gets the impression that some of Ada's
big backers hoped that their wonderful language would do away with the need for
competence. After all, it's much easier to run a test suite through a compiler
than to decide whether a programmer is competent.
The C community regularly sees broadsides on the subject, with ignorant people
claiming that the large number of "implementation defined" or even "undefined"
items in ANSI C implies that C programs cannot possibly be portable or
reliable. Not so; these are just indications of where the programmer must
avoid depending on implementation-dependent behavior. (There is room for
legitimate debate about whether C expects too much from its programmers, but
that is a different issue. Portable, reliable C code is verifiably possible.)
C gets more of this than Ada, because C is a rather unforgiving language meant
for people who know what they are doing, but almost any efficient language will
run into similar issues.
To draw an analogy from more traditional engineering, the basic art of
designing circuits with transistors is organizing things so that the
characteristics of individual transistors do not affect the outputs much.
Transistor characteristics are quite variable, especially if you want the
transistors to be cheap. This does not make it impossible to design transistor
circuits with predictable properties. It merely requires that designers take
care to use circuits that allow for the variability and cancel it out.
Henry Spencer at U of Toronto Zoology henry@zoo.toronto.edu utzoo!henry
Please report problems with the web pages to the maintainer