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…
The next complaint was sent to rec.radio.shortwave.
jaap (jaap@research.att.com)
From: Lee.Laird@f7009.n124.z1.fidonet.org (Lee Laird)
Newsgroups: rec.radio.shortwave
Subject: forwarded from
Date: 28 Feb 92 22:41:00 GMT
Article-I.D.: ocitor.699420553.F00002
Posted: Fri Feb 28 17:41:00 1992
Sender: FredGate@ocitor.fidonet
thanks to the authors of Imail — feb 29 has caused systems to
crash worldwide since the mail tosser and handler does not recognize
the date and locks up the system..
any outgoing dates with 29 feb also has that problem ... to overcome
the problem and move the messages from my system i have had to set
the date back and forward messages containing 29 feb ....
PLEASE DO NOT SEND REPLIES TO ME !!!!!!!
reply to those who i forwarded the message from... thanks. lee
* Origin: -Com Port 1 DFW Amateur Radio BBS (214) 226-1181 (1:124/7009)
All right now, how many people reading this have watches that need to be set back a day because they went directly from February 28 to March 1-- and *hadn't realized it yet*? (See Risks-6.34 and 6.35 for the previous version of this message, and commentary on this and other leap-year problems.) Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb, msb@sq.com
Working on my home computer on Saturday, I noticed something interesting. One computer was smart enough to handle the leap year with no problem. The other *would not accept* a February 29th date ... but was smart enough to know that March 1st was a Sunday. Oh, well, I didn't get much done Saturday anyway ...
As most RISKS readers know, February 29th is International Software Calendar Bug Day. Yesterday's quadrennial event found a bug in Prime's MAGSAV program that caused the program to fail promptly at midnight, as reported in the Usenet comp.sys.prime newsgroup by Peter Maurath. Ironically, the big day was a Saturday, and Prime's 800 number for software support doesn't work on weekends. (Message-ID <17174.29aee0a1@bclcl1.im.battelle.org>) In the same forum, Richard H. Miller reported the usual workarounds: either use an older version of MAGSAV, or lie about the current date. He wrote, ``The indication is that it `snuck up on them' to paraphrase the Prime support person I talked with.'' (Message-ID <10383@gazette.bcm.tmc.edu>)
The state of Iowa made a bit of a mistake this year. All liquor licences that
should expire at the end of this Februrary expired today, on the 28th. The new
licences only become valid on March first, so a large number of liquor stores,
bars and restaurants have no liquor licence tomorrow (leap day). The state
liquor control people have announced that this was due to a "computer error"
and they promise not to enforce the law tomorrow, at least, not as it applies
to those caught by this glitch.
Doug Jones jones@cs.uiowa.edu
As people may know, the rock band U2 is starting a tour soon and is playing
venues much smaller than the number of fans who would like to see them
(13,000 seat arenas when they could easily fill 50,000+ seats).
The group has been going to extraordinary lengths to prevent ticket scalpers
from getting tickets, including selling some venues by phone only. This has
led to some real messes (as when they put the tickets for the Boston Garden
show on sale. Half a million calls in the first hour).
One good computer-related side effect came to light the other day with the
suspension of the manager of the Providence Civic Center. Seems this
gentleman stands accused of deliberately overselling his arena with the
extras going to scalpers. His scam was shut down after 150 extra tickets
were sold. The oversell was detected by U2 people who were monitoring
ticket sales from the central computer site in New York City.
So for once computer monitoring worked the way it should. And in a widely-
distributed system under high stress. Not too shabby.
Additionally, each ticket sale was verified to ensure that no one made
duplicate orders. According to local radio reports, computer checks for
duplication were made against "name, address, and credit card number." "450
duplicates were caught" and the orders cancelled after "human verification."
Again, I applaud appropriate use of technology — the computer did the dumb
brute work of finding possible matches and coughed up data to a human being
for verification.
I'm sure someone will write in with information on what telephone services
were denied during the deluge of calls, but hey, nothing's perfect.
--Alan Wexelblat, Bull Worldwide Information Systems, Billerica, MA
phone: (508)294-6120 wexelblat.chi@xerox.com
A recent article by reporter Jay Bryan of the Montreal Gazette in the paper's
business section made some extraordinary claims about the effect that bugs in a
newly-installed integrated computer program had on the demise of a
Montreal-based life insurance company.
It also has some things to say about both systems administration and systems
integrators that might be of interest to the comp.risks readership.
The article begins:
"When Montreal Life Insurance Co., a growing, profitable insurer, decided to
upgrade its main computer program 10 years ago, it jumped in with both feet.
The new program, a kind called an integrated one, [ yeah, right :-)] would tie
together every aspect of the company's operations.
There was a small problem, though. The enormous program had been customized and
installed in haste. Scattered through its one millions lines of computer
instructions, there were a few undetected bugs. And since the system was
integrated, every time a bug caused an error in one department's files, the
error was immediately reflected in several other departments' files.
Within a year, Montreal Life was losing money. After three years, the company
was near collapse. errors in commission cheques, for example, drove away most
of the company's agents. The agents took their clients with them. When agents
weren't underpaid, they were overpaid, which accounted for another $1 million
in losses.
Finally, what remained of Montreal Life was sold by its owners
and most of the company's top managers lost their jobs....."
This horror story is credited to two "systems auditors", Marshall Govindan and
John Picard, who "... are determined to send a wake-up call to all those
corporate leaders who think running a caompany's information system is just a
housekeeping detail." Govindan apparently once worked for Montreal Life.
Despite its apparent "scare tactics" tone, the article goes on to discuss the
need for proper systems management practices in which it makes a couple of good
points about the need for suitable direction to systems staff from upper
management. The point is made that "The systems people are basically a law unto
themselves. They're accountable to nobody...this is because systems managers
are treated as a kind of technological high priesthood. Their knowledge is
considered so esoteric that top managers feel helpless to help them to the same
standards of performance that are common in areas like marketing, operations
or finance."
Apparently Govindan and Picard have written a book on the subject entitled
"Manifesto on Informations Systems Control and Management", published by
McGraw-Hill Ryerson. No further details of the book were given.
The article then describes a "success story", the Wal-Mart chain of retail
stores, which apparently managed to speed checkout handling and minimize
stocking with suitable, timely application of new technology.
The article finishes with a description of how a successful systems integrator
works to bring up new technology and manage the transfer of new clients onto
their systems while minimizing their disruptions. The conclusion was "All this
[careful client handholding] is a 'pain in the neck' for systems people who
might prefer to be doing something more technologically glamorous than sweating
over every detail of every new installation...But from the perspective of the
company, it means happy customers, rising sales and an assurance that the new
system will produce steady profits instead of unexpected losses."
The article appeared in The Montreal Gazette, Saturday, February 22,
1992 on page C1 of the Business section, continuing onto page C4.
The risks are obvious. The tone is a tad alarmist, but if true, the tale of the
demise of Montreal Life contains lessons for those who would rush into
implementation of such mission critical software, and then insist on staying
with such an obvious failure for as long as three years. I would therefore
suspect that the tale of the fall of this company has a lot more that was left
unsaid. Would any comp.risks readers have any more details on this?
- peterd
Speaking of the post office — (I know that another Ithacan has complained to
you about the way mail gets forwarded in Ithaca, but I thought I'd add my
husband's mail-forwarding story.)
Last November my husband tried to use his ATM card over the Veterans' Day
holiday weekend. The person in front of him successfully acquired cash from
the ATM, but when he tried to get some money he got the uninformative error
message "We're sorry, but we're unable to process your transaction right now."
(This is the same message you might get when the machine is out of money, which
often happens to this bank's machines during holiday weekends.) So he assumed
he was just particularly unlucky that the person in front of him took the last
of the cash in the machine.
The next day he tried at a different machine, again just after someone had
taken out some money. He got the same message about not being able to complete
the transaction. Frustrated, he tried small amounts of money, $10, $20,
thinking perhaps the machine was out of particular bills. That didn't work
either. We also have an ATM card for our joint account with the same bank. He
tried that card and it worked fine.
(No, he didn't forget his PIN number and yes, the card was in one piece,
and yes, this really does have to do with the Post Office.)
Puzzled, he called the bank after the holiday and asked them why the ATM card
for his account didn't work. They looked up his record and said "Well, it's
because your last statement got returned to us 'addressee unknown'." So part
of the story is that the bank was stupid and didn't call to verify if he had
moved (he hadn't), and locked out his ATM card. And part of the story is that
my husband didn't realize he hadn't yet received his bank statement for the
previous month. But the rest has to do with the way the Post Office forwards
mail.
The bank gave him the statement that was still in its envelope with
several yellow forwarding stickers on it. The hash function that the
Post Office uses (at least in the Rochester branch of the Post Office)
is first 3 numbers of the street address and the first 4 letters of the
last name. My husband has a pretty common last name (Chang).
Evidently, a Chang with a different first name who lived at a house
numbered 216 on a completely different street (in a different section
of Ithaca so the 9 digit zip codes didn't match either) recently moved
out of Ithaca. Since my husband's name and address matched the 216CHAN
hash function for forwarding, his statement was accidentally forwarded,
and eventually got returned to the bank. Obviously, no one ever really
compared the 2 addresses because the street names were very different.
All sorts of risks in this whole scenario, but what I can't understand is why
the Post Office uses just these 7 characters for their hash function. Seems
like there should be a way of using a character from the person's first name
and the street name to make it work a little better. Our friend Jenn Turney
had problems a few years ago when someone named Turner (with a different first
name, and different street name, but the same 3 digit house number) moved.
Scanning the phone book, I wonder if Andy Chan, Kenneth Chan or Sak Chanthanak
(all with 216 house numbers) have had any problems with their mail being
forwarded...
Christine Piatko (piatko@cs.cornell.edu)
The recent MBDF-A virus which was (allegedly) uploaded to SUMEX-AIM by two Cornell students shows a possible risk: it seems likely that the students were tracked down via examination of machine logs, both at Stanford and at Cornell. They might have been aware of the "last" log, showing who was logged in to what machine when, but probably were not aware that "anonymous" ftp accesses are routinely logged. While the username which you provide can, of course, be anything, it is much more difficult to disguise the source of the FTP transaction, and this can be logged. The risk is not so much that the logs are made, but more that the service is presented as "anonymous", leading people to believe that it actually is. William Rucklidge wjr@cs.cornell.edu
This morning I happened to catch newsman Charles Osgood's "The Osgood File" on the local CBS AM all-news station. "The Osgood File" is a two-minute long daily radio "column" in which Mr. Osgood talks about something in the news that interests him. Today the topic was the "Michaelangelo" computer virus. Mr. Osgood spoke repeatedly of the danger to "your computer", and had a brief interview with a computer consultant who also spoke of the danger to "computers". AT NO TIME DURING THE PIECE DID ANYONE MENTION THAT THE VIRUS AFFECTS MS-DOS CLONE MACHINES ONLY. The gist of the piece was that viruses are bad and that all computers are in horrible danger of losing their files on the fateful anniversary this Friday. I called Mr. Osgood's office in New York City and spoke to a woman who was very pleasant to me, and seemed surprised that that particular bit of information had not been included. I'm not sure I was forceful enough in stating how crucial the missing information was to the story. I still can't believe that it was omitted.
James Paul just sent me a copy of a report to the Chairman, Subcommittee on
Investigations and Oversight, Committee on Science, Space, and Technology,
House of Representatives, from the US General Accounting Office, entitled
Patriot Missile Defense: Software Problem Led to System Failure at
Dhahran, Saudi Arabia. GAO/IMTEC-92-26, February 1992
along with letters from the Subcommittee Chairman, Congressman Howard Wolpe
(Michigan) to Richard Cheney, John Conyers (Chairman of the Committee on
Government Operations) and Les Aspin (Chairman of the Committee on Armed
Services). If any of you want to see the report and/or the letters, please
contact James Paul at paul@Nova.House.Gov or call 202-226-3639. You may also
get a copy of the report directly from the US GAO, 202-275-6241; single copies
of the report are free.
The details are mostly known to RISKS readers. Appendix II shows the effect of
extended run time, with a .3433 second time inaccuracy over 100 hours, and a
shift of 687 meters in range gate.
[Science Committee staffer James Paul was the author of the remarkable 1989
report, Bugs in the Program: Problems in Federal Government Computer
Software Development and Regulation.]
[I presume you all saw the Scud item in RISKS-13.19.]
> Any comments from qualified persons? My only qualification is that I have read the interim report of the commission of enquiry into the Strasbourg crash, and a few other documents. > MOST 320 aircraft have an alarm that informs the pilot that s/he > is flying too low, but France does not require this alarm and so aircraft > sold to and/or operated by French companies do not have this alarm installed. The Ground Proximity Warning System (GPWS) is standard equipment, and is mandated by international regulations. Air Inter, which operated the A320 which crashed at Strasbourg, are a purely domestic airline. Since their aircraft do not fly outside France, they are not covered by the international rules. Air Inter took a deliberate policy decision many years ago *not* to use GPWS, since such systems are (or were then) prone to giving false alarms. They argued that, in any case, their pilots were highly familiar with the terrain around the airports they served, and so didn't need GPWS. In its interim report, the commission of enquiry has been *very* careful not to draw any conclusions, or even entertain any theories, about the cause(s) of the crash. However they are aware that the use of GPWS would have made an accident of this type less likely, and the second of their three interim recommendations is that the French national regulations are amended as soon as possible to make the installation of GPWS mandatory on all aircraft large enough to carry one, including those used only on domestic routes. Note that international carriers, such as Air France, *are* covered by international regulations, and have always had GPWS in their A320s. > If so, this points to a particularly interesting human interface problem -- > perhaps the A320 tends to drop faster than other aircraft, but, since there > is no alarm, [some] pilots do not realize what is happening until they're > too low to do anything about it. The human interface problem which most concerns the commission, and which is the subject of their first interim recommendation, is the possibility of confusion between the two modes of descent: "Vertical Speed" and "Flight Path Angle". For a detailed description of how this confusion could arise, see Robert Dorsett's excellent description of the Flight Management System (FMS) in RISKS-13.11. One possible effect of the pilot selecting the wrong mode is that the aircraft would descend much faster than intended. Apart from that situation, as far as I know the A320 drops neither faster nor slower than any other airliner. On 28th January, the DGAC (French equivalent of the FAA) warned users of the A320 about the danger of confusing the two modes, and immediately put in place procedures and documentation to prevent this happening. The French Minister of Transport has directed the DGAC to monitor the effectiveness of these temporary measures carefully, and told them to direct Airbus Industrie, who manufacture the A320, to produce a detailed plan (within one month) of modifications to that particular part of the pilot-FMS interface. The implementation and certification of the modified FMS will obviously take much longer. Again, the report stresses that this recommendation does *not* imply that the commission have concluded that confusion of descent modes is the cause, or part of the cause, of the Strasbourg crash. The commission's third interim recommendation (again backed up by the Minister) is to make the automatic emergency radio beacon less likely to be damaged in a crash. At Strasbourg it was destroyed, and this has been suggested as one reason why it took rescue teams so long to get to the crash site. The Minister added a fourth directive to the DGAC to look into more rugged flight recorders, and improved protection for them. At Strasbourg, the Digital Flight Data Recorder (DFDR) was fried to a crisp, and the Cockpit Voice Recorder (CVR) and Quick Access Recorder (QAR) were damaged, but still readable in parts. In the last three years there have been five accidents in which the recorders have been destroyed, according to the Minister's statement last Monday. Recorders and emergency beacons are useful only after you've already crashed the 'plane, of course. Whether the crash could have been averted if a GPWS had been fitted is obviously still an open question. It would depend on the length of time before impact at which the warning would have been given, and I do not have this information right now. There is, however, another system, the radiosonde alarm, which gives a simulated voice warning as the aircraft passes down through certain thresholds of altitude, measured by a radio beam reflected from the ground. The top threshold is 200ft. This is separate from the GPWS, and *was* in use on the Strasbourg A320. The transcript of the CVR shows a single radiosonde announcement of "Two hundred feet". Although no time stamp is shown on the CVR transcript, this is the last thing that appears, and seems to have occurred a mere second or so before impact. Peter Mellor, Centre for Software Reliability, City University, Northampton Sq., London EC1V 0HB, Tel: +44(0)71-477-8422, JANET: p.mellor@city.ac.uk
On 25 Feb 1992, the papers here reported on the interim report of the French
commission of inquiry into the Strasbourg A320 crash. Although they emphasise
that they have not concluded what caused the crash it seems they are leaning
towards the confusion of the vertical speed and flight path angle modes of
descent as desribed by Robert Dorsett in risks 13.11. To show how confusing
this is, the reports in the Times and the Independent (2 quality UK papers)
contradict each other on the mode that the pilots should have been using.
>From the Independent:
The French government yesterday ordered modifications to the instruments
of the Airbus A320, one of which crashed near Strasbourg last month.
Paul Quil\`es, the Transport Minister, said the changes would affect the
systems controlling descent. [He wanted Airbus] to report within one month
on how it would carry out the modifications. ...
The commission ... recommended to ``the ergonomics of the aircraft-crew
interface linked to the `Vertical Speed' and `Flight Path Angle' modes''.
On the A320 ... pilots select a pattern by pressing a button on the
instument panel. The choice is determined by pressing the button once
or twice. The Flight Path Angle would have been normal for the Strasbourg
approach.
[end quote]
The story goes on to say that the government were ordering that GPWS
should be installed in all aircraft. Air Inter did not have this as they
had had reliability and false alarm problems with them.
It also mentions the problem of slippage between the A320's map display and the
position on the ground. Air France and Air Inter had stopped using this after a
pilot flying into Bordeaux noticed a difference between indicated and real
positions. The commission are not saying that this problem was linked to the
Strasbourg crash but the report says that the cockpit voice recorder indicates
that the pilots were concentrating on their lateral position just before the
crash.
>From the Times:
The manufacturers of the A320 ... are to seek new ways of making their
jets ``pilot-proof'' and preventing crews from mistaking their flight path
angle for their speed of descent.
Air accident investigators ... have yet to find the precise cause ...
but their preliminary report suggests that the pilots could have programmed
the computer wrongly because of confusion over the role of one of the
instruments. ...
As they approached Strasbourg and were told to make a standard descent,
it is now thought likely that they ordered the aircraft to descent at an
angle rather than at so many feet per minute.
[end quote]
The Times report is written with much more emphasis on pilot error. It doesn't
mention the government order to Airbus to change things or the map problem.
On Sunday 1 March the Sunday Times, a `heavyweight' (in both senses of the
word, 9 sections and stilll growing) UK paper had a piece in its business
section headed `Airbus has worst record'.
Airbus Industrie, the European aircraft consortium, has suffered a new
setback with the revalation that its A320 currently has the worst accident
record of large passenger jets registered in Britain.
An insurance industry report shows that crashes involving the plane,
the most advanced flown by airlines, have led to a higher death rate among
passengers than on aircraft designed nearly 25 years ago.
...
Paul Hayes, director of Airclaims, the aviation consultancy which drew
up the report, said it was too soon to draw conclusions over the safety
of the four-year-old A320. ``Its loss rates are worse at the moment but
this does not mean that it is a dangerous aircraft. If these are
maintained over a longer time, however, it may indicate a serious problem
for ASirbus,'' he said.
The report examines the loss and fatality rates for all jet and turbo-prop
aircraft over the past five years. It shows that one person was killed
on A320s for every 331,900 carried, compared with one for every 1,401,100
on DC10s, the next worse. If the French disaster was included, the A320
figure would drop to one for every 270,000, a record more than eight times
worse than the average for its generation of jets.
The aircraft is shown to have had a fatal accident for every 241,700
landings, seven times worse than the performance of the Boeing 757, one
of its main rivals. The older A300 and A310, which do not use the
contoversial fly-by-wire system, have not had a fatal accident.
...
Airbus said it was unfortunate that aircraft crashes were remembered
for the type of plane involved rather than the cause. ``There have been
three crashes and in the first two it was quite clear that the aircraft
was not at fault,'' a spokeswoman said.
[end quote]
Airbus' comments in the last paragraph of this report seem suspect to me.
Unless you assume that the pilots flying A320s are more stupid than
average, then if pilots have more crashes in A320s than other planes,
even if the cause is officially `pilot error', there must be something
about the plane that makes errors more likely.
Peter Ilieve peter@memex.co.uk
Please report problems with the web pages to the maintainer