Subject: RISKS DIGEST 13.72

Subject: RISKS DIGEST 13.72
REPLY-TO: [email protected]

RISKS-LIST: RISKS-FORUM Digest Wednesday 12 August 1992 Volume 13 : Issue 72

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

Contents:
Electronic Voting Machines Alert (Rebecca Mercuri)
NWB credit-card errors affect millions (Philip Hazel, Jonathan Bowen)
Cash Card Fraud - the public fights back (Brian Randell)
"Around the state at Barnett Banks, it did not compute" (Norm deCarteret)
The QE2 and navigational charts (John Sullivan)
Stupid computers--The Economist reports on AI (John Sullivan)
GAO reports on NASA (James Paul via PGN)
Re: Ship ... tips over (Cristobal Pedregal Martin)
Re: Stupid things people do (Joseph F. Hull)
Re: Bug or Fraud (Michael Friedman)
RISKS of DOS, Caller-ID, Voice Mail... (Peter da Silva)

The RISKS Forum is moderated. Contributions should be relevant, sound, in
good taste, objective, coherent, concise, and nonrepetitious. Diversity is
welcome. CONTRIBUTIONS to [email protected], with relevant, substantive
"Subject:" line. Others may be ignored! Contributions will not be ACKed.
The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS,
especially .UUCP folks. REQUESTS please to [email protected].

Vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR>
CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 13, j always TWO digits). Vol i
summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out.
The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1".
<CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password.

For information regarding delivery of RISKS by FAX, phone 310-455-9300
(or send FAX to RISKS at 310-455-2364, or EMail to [email protected]).

ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.

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

Date: Wed, 12 Aug 92 04:16:11 EDT
From: [email protected] (Rebecca Mercuri)
Subject: Electronic Voting Machines Alert

On July 23, 1992, New York City Mayor Dinkins announced in a press conference
that the $60,000,000 contract to replace the city's mechanical voting machines
with electronic voting systems (EVM) would be awarded to Sequoia Pacific,
pending the outcome of public hearings.

The city's press release included the following statement:
"In January 1989, SRI determined that Sequoia Pacific was best
positioned and most willing to modify its system to meet the
needs of New York City and New York State standards."

In actuality, SRI's Final Report (Evaluation of Offerors for the Procurement
of an Electronic Voting System, December 23, 1988) contained the following
first sentences under FINDINGS:
"No offeror's system completely meets the RFP specifications.
On the basis of our analysis and the testing of the EVMs,
SRI concludes that no offeror currently has either an EVM
or central system acceptable for the city."
They went on to say:
"No offeror scored higher than 63% of the total possible RFP
and evaluation criteria points."
And:
"SRI does not believe any of the four offerors has fully met
the requirements of the RFP, based on their proposed EVMs,
their central systems, and/or management and financial
considerations. Each offeror would have to make substantial,
significant modifications and additions -- in both technical
and management areas -- for its approach to be considered
acceptable for the City."

SRI went on to recommend Sequoia on the basis that of the four offerors,
they had the greatest "probability of ... successfully implementing an
electronic voting system for New York City."

Does the record indicate that Sequoia has or can successfully implement
a system for New York City? You decide. Here is some information from
public documents:

Monroe County, Indiana vs. Sequoia Pacific:
"In December, 1988, Monroe County, Indiana, filed a lawsuit
against A. E. Boyce and SP, alleging that the defendants
breached a contract between the County and Boyce whereby
Sequoia was to have manufactured and Boyce was to have
delivered to the County 120 automatic voting machines.
Only 40 of the machines were delivered and Sequoia
subsequently ceased production of the model which was
the subject of the contract." "In December, 1990, the
case was settled by the parties. The contract in question
was terminated..."

On July 11, 1990 the Sequoia Pacific Electronic Voting System was denied
certification in the state of Pennsylvania on the following grounds:
"(1) The system does not conform to Pennsylvania statutory
requirements for overriding straight-party votes in individual
offices; (2) the system can be placed inadvertently in a mode
in which the voter is unable to vote for certain candidates,
which is volative of statute; and (3) the system reports straight-
party votes in a bizarre and inconsistent manner."
The NY City Board of Elections stated in a letter on January 3, 1991 that:
"The vendor has admitted to us that release 2.04 of their software
used in the Pennsylvania certification process had just been
modified and that it was a mistake to have used it even in a
certification demonstration."

In what appears to be the final updated evaluation by SRI (June 19, 1991)
of the Sequoia Pacific EVM and its Programmable Memory Device (PMD) which
contains the vote tally, under the heading of Reliability, the testing
status report from Sequoia Pacific stated:
"SP doesn't know how to show that EVM/PMD meets requirement --
this depends on poll workers' competence."

If the above concerns you, here's what you can do:

1. Attend and comment at the public hearings in New York City. It is
critical that individuals have their opinions on this matter stated
for the record, BEFORE the contracts are presented for signing.
New York City residents as well as ALL other interested parties
are permitted to attend.
The meetings are:
August 20, 42nd & Broadway, 6th Floor, 6PM
September 10, City Hall, 10AM (tentative)

2. Request documents from the city under the Freedom of Information Act.
Contact Lorraine Jones at 212/566-3307 in the Department of General
Services. You may wish to request all or some of the following:
A. SRI Final Report, Volume I, December 23, 1988,
Evaluation of Offerors for the Procurement of an
Electronic Voting System.
B. SRI Updated Evaluation of the Sequoia Pacific EVM,
June 19, 1991.
C. Technical Specifications including -
System Requirements Documents
System Design Documents
System Quality Documents
System Verification Plan
System Test Plan
Results of Entire System Test
D. A list of other publications relevant to this matter.

3. Write letters of concern and comment to:

Daniel DeFrancesco
Executive Director
Board of Elections
City of New York
General Office, 32 Broadway
New York, NY 10004

cc separate copy to
Stephanie Dawson
Director, NYC Elections Project
at the address above

Kenneth Knuckles
Commissioner
Department of General Services
Municipal Building, 17th Floor
New York, NY 10007

cc all correspondence to
Election Watch
P.O. Box 1166
Philadelphia, PA 19105

4. If you are a member of ACM, IEEE or other professional, computing or
engineering organizations, encourage your officers and club members
to become involved and informed on this issue.

5. Forward this posting to everyone you believe would be interested in
commenting on this matter.
Rebecca Mercuri [email protected]

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

Date: Wed, 12 Aug 92 10:09:31 BST
From: Philip Hazel <[email protected]>
Subject: NWB credit-card errors affect millions

Is there a record for the greatest number of people affected by one computer
bug? [This is most likely not it. But it also depends on how you define
"affected"... PGN]

BANK WARNS CREDIT CARD CUSTOMERS [Cambridge Evening News, 11 Aug 1992]

Millions of credit card customers are being contacted to be told their
statements might be wrong. NatWest [the National Westminster Bank] is to tell
its five million cardholders about the possibility of errors caused by a
computer problem - and millions of cardholders with other banks who also have
their accounts processed through the same system could be affected. But no-one
will lose money as a result of the errors, said a NatWest spokesman. [No-one?
Not even the banks? You bet, not the banks...]
The mistakes have come about because of a "blip" in the computer system run
by First Data Resources. Cards affected include Visa, Mastercard and Access
supplied by NatWest, Midland and Lloyds. `We will be correcting it all
ourselves. There will be no need for the customer to contact us', said a bank
spokesman.

[This item was also reported on ITN's TV newscast, where they interviewed a
customer whose statement had spuriously acquired a debit for over 4,000
pounds. The credit card bill had automatically been paid from his regular
bank account by Direct Debit, thereby making the bank acount overdrawn and
attracting heavy interest charges.]

University Computing Service, Computer Laboratory, Pembroke St, Cambridge CB2
3QG, England [email protected] JANET: [email protected] +44 223 334714

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

Date: Wed, 12 Aug 92 14:47:43 BST
From: [email protected]
Subject: Bugs and bytes bedevil those paying by plastic (Re: Hazel)

[... Jonathan sent in a bunch of further stuff
on this topic, excised for brevity. PGN]

Last night's ITN 10 o'clock news was rather more sensationalist, showing a
short clip of someone on the phone complaining about an unexplained debit of
over 4000 pounds sterling (c $7,500) entry on his account. Surely this must
have been a set-up!

Jonathan Bowen, Oxford University, a Midland VISA card owner.

[In addition, [email protected] sent in a copy of a U.S. State
Department advisory along similar lines. PGN]

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

Date: Wed, 12 Aug 1992 10:50:42 +0100
From: [email protected]
Subject: Cash Card Fraud - the public fights back

The following is the latest in a series of articles that I have seen in various
papers over the last few months about a growing campaign against the practice
that UK Banks have of assuming that all cash card fraud is due to stolen or
misused cards and pin numbers. (This continues despite the case of the proven
cash card fraud carried out by an engineer working for the Clydesdale Bank, if
I remember correctly, who eavesdropped electronically on cash dispensing
machines.) As I understand it, class actions are comparatively rare and
difficult in the UK, so the story is locally interesting just for that reason.
However I have not before seen any mention of the way that the barrister
leading the action has arranged for computer database and communications
technology to be used to gather evidence to counteract the banks' claims -
hence this posting to RISKs. Brian Randell

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

Banks face legal challenge over cash card fraud
By Susan Watts, Technology Correspondent, The Independent, 12 Aug 1992

People convinced they have lost money through cash dispenser fraud could
have a novel computer system to thank if they succeed in legal action
against their banks due to start tomorrow.

Alistair Kelman, a barrister acting for aggrieved customers in a case against
seven high street banks and building societies is using computer software to
spot patterns in the way unauthorised transactions take place. Mr Kelman has
built up a computer database holding information on more than 400 cases. His
"relational" database allows him to cross-correlate the place, date and time of
mystery cash withdrawals. He hopes to match cases with similar characteristics
in a way that he says the banks have so far failed to do. The database will let
him analyse "the spider's web" of automatic teller machines across Britain, he
said.

"I don't think the banks are capable of doing what we are doing. They would
only have the pattern of their own branch or their own banking network."
Rebecca Evans, a barrister working for the Consumers' Association, said she had
already noticed that victims often lived in the same area. Banks have also
claimed phantom withdrawals occur near the victims' local cash machine,
implying that their personal identification number has been passed on or
stolen. She said the database should help to support or dispel such theories.

Mr Kelman believes the case is unusual in that it enlisted help from
thousands of interested observers via a computer "conference" on the
Compulink Information Exchange. This type of electronic message service
lets people add their ideas to computer-based "conversations" via telephone
data links.

Mr Kelman said the case had attracted about 5,000 contributors including
policemen, people offering advice on how to make phantom cash withdrawals and
others who had had first-hand experience of cashcard theft. One story added to
the computer bulletin board recently was from a man claiming his high street
bank account was debited from Scotland while he was sitting an exam in Chester
with the card on his desk as proof of identification. The bank involved paid up
almost immediately, despite the banks' persistent claim that their machines are
infallible.

Mr Kelman said that linking the cases via his database has enabled him to bring
a "group action" against the financial institutions.

Denis Whalley, associate solicitor at Keith J Park in Merseyside who is
preparing the cases, said Mr Kelman's approach had helped him secure legal aid
for many of the plaintiffs even though most were claiming less than
(pounds)1,000, which would normally be too small a claim to qualify. He intends
to issue writs on 10 cases tomorrow, then add to these over the following
months to work towards a full trial next summer.

Mr Whalley said the banks had become more willing to pay up as his court case
approached. But a spokesman for the Association of Payment Clearing Services
the banks' cheque clearing system insisted yesterday that the banks were
confident in the security of their computer systems and fully prepared to face
the court action.

Dept. of Computing Science, The University, Newcastle upon Tyne, NE1 7RU, UK
[email protected] PHONE = +44 91 222 7923 FAX = +44 91 222 8232

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

Date: Wed, 12 Aug 92 08:50:50 EDT
From: Norm deCarteret 813-878-3994 (TL 438) <[email protected]>
Subject: "Around the state at Barnett Banks, it did not compute"

Source: St Pete Times, 8/12/92, pg E1, Robert Trigaux

By the close of business Tuesday, Barnett Banks Inc had learned what it is like
to be an 800-pound gorilla wearing a blindfold. Florida's largest banking
company opened its 550 branches statewide Tuesday only to find its computers
were taking the day off...branches could not open a new account or check
balances in any customer's account.

Most branches set dollar limits on cashing checks and worked to minimize the
confusion. But Barnett customers with big transactions to make and who did not
pass a 'Do I know you' test of branch managers were out of luck for the day.
..

Though computer experts spent most of Tuesday in search of the 'bug' that
plagued Barnett's systems, they were not able to identify it and fix it before
most of the bank's offices closed at 4 PM. As it turned out, a single
transaction ground Barnett's two giant mainframe computers to a halt, according
to Jonathan Palmer, Barnett's chief technology officer.

"A coding error in a program caused our whole computer complex to 'hang up' ...
That one transaction acted like a computer virus" by redirecting the computers
from their appointed tasks. Barnett is working on new systems to avoid any
repeat of Tuesday's troubles. "This should be an extremely rare occurrence,"
Palmer said.

| A more detailed description of how the bug "redirected" their
| computers and in such a way that the offending transaction couldn't
| itself be located or help find the bug during the whole day would
| be interesting. Other risks naturally include being a bank user
| who customarily uses ATMs or uses different branches for convenience.

Norm deCarteret IBM Information Network Tampa FL

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

Date: Wed, 12 Aug 92 11:34:11 CDT
From: [email protected]
Subject: The QE2 and navigational charts

The ocean liner QE2 had its hull damaged sailing near Martha's Vineyard.
Nautical charts of the area (made in 1939) show a shoal at a depth of 39 feet
(surrounded by readings of 85 and 90 feet) near where the ship hit something.
The ship's draw is listed as 32 feet, which should have left seven feet to
spare. (Of course, it is not known if this is what was hit, or if the pilot, a
local pilot brought on board to navigate coastal waters, would have tried to
stay clear of that ledge even if there was supposed to be seven feet
clearance.) The entire area has been known as a dangerous one for ships for
centuries, though the QE2 was in a standard navigation channel, heading for
NYC.

An article in the NY Times today (12 Aug) points out that the nautical charts
are based on a "sonar technology that may have overlooked higher peaks or
boulders on an underwater ledge", described by an NOAA spokesman as "hit or
miss". He said "It is possible that the survey missed a shallower depth, that
the survey passed around it and didn't see it."

It surprises me that surveyors, when finding a steep shoal like this, 50 feet
higher than the surroundings, would not look specially for its tip. This
points out the danger of digitizing real world data onto a fixed grid.

Today's article in the Times (by Felicity Barringer) ends by noting that "at
least two of the ship's three electronic navigational systems were operating at
the time" of the accident.

-John [email protected]

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

Date: Mon, 10 Aug 92 14:03:24 CDT
From: [email protected]
Subject: Stupid computers--The Economist reports on AI

The Aug 1st issue of the Economist has an editorial and article on "Stupid
Computers". They say attempting to pass the Turing test is a bad idea, because
computers think differently than people. Computers and people can complement
each other. American Express, having computerized its credit card division,
can now hire humans who are good at dealing with people (instead of at number
crunching), and can give them more freedom to solve customers' problems (with
the computer's help).

The article starts out:
Every customer has at least one horror story to tell of a company
or a government deptartment that is unable to stop sending wrong bills,
or to correct an address, or to divulge a piece of information "because
of the computer". Teh brainless obstinacy of some machines has made
them great allies of bureaucratic solution blockers. So the very
thought of giving machines more responsibilities will send chills down
many spines. Fear not. Companies are findin that the more intelligent
machines are allowed to play to their strengths. the more they reduce
human obstinacy.

However, it does conclude on a note of fear:
Someday someone will inevitably go too far. Bankers, for example, are
talking about using artificial intelligence to enable their people to
sell financial products too varied and sophisticated for the salesmen to
understand. Now that is an intelligent idea that could leave someone
looking very stupid indeed.

I don't see qualitative difference between this scheme and the one that allows
American Express to hire people who don't understand the number crunching.

-John [email protected]

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

Date: Tue, 11 Aug 92 10:36:07 PDT
From: "Peter G. Neumann" <[email protected]>
Subject: GAO reports on NASA, the latest from James Paul, [email protected]

* Space Station: NASA's Software Development Approach Increases Safety [Risks]
and Cost Risks. US Government Accounting Office. Report to the Chairman,
Committee on Science, Space, and Technology, [U.S.] House of
Representatives, GAO/IMTEC-92-39. June 1992.

[The above title was DISAMBIGUATED by the insertion of "[Risks]" by PGN.
The first time I read the title, it seemed to suggest that the approach
increases safety. The text clearly indicates that is NOT what was meant.]

* Space Shuttle: NASA Should Implement Independent Oversight of Software
Development. US Government Accounting Office. Report to the Chairman,
Committee on Science, Space, and Technology, [U.S.] House of
Representatives, GAO/IMTEC-91-20. February 1991.

Copies may be obtained directly from the GAO (P.O. Box 6015, Gaithersburg MD
20877), or through James Paul ([email protected] -- if his system is up!).
These are relatively incisive and useful reports. Thanks, James! PGN

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

Date: Fri, 7 Aug 92 21:12:28 EDT
From: [email protected]
Subject: Re: Ship ... tips over (Jacky, RISKS 13.71)

[Jon Jacky reproduces _Seattle Times_ item on a ship that leaned
left then right, the article then says:]

> Tacoma Boat, which built the Dona Karen Marie, [...]

"Tacoma" seems to have something with to do with bad oscillations :-)

Cristobal Pedregal Martin, Computer Science Department, UMass/Amherst MA 01003

[It certainly Narrows ones thinking! PGN]

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

Date: Tue, 11 Aug 92 14:56:31 MDT
From: [email protected] (Joseph F. Hull)
Subject: Re: Stupid things people do

I was working as a programmer for a military command center, the kind with
large screens around the walls which display current status of whatever. The
system was a custom job with custom software, but was fairly stable (no
outstanding software problem reports, no recent modifications). Normal
operations 24 hours / day, 7 days / week.

One Monday morning about 0600, the system crashed. No problem. The operator
initiated warm start on the hot backup system and dump procedures on the failed
machine; back on-line in less than 3 minutes (and called me, midnight shift
programming support). A few minutes later the alternate system crashed. What
to do? (The dump takes about 11 minutes. If we abort the dump to get on-line
as fast as possible, we lose any chance of finding out why the first crash
occurred. And the primary system may go down again if we have an unrepaired
hardware problem. But since both systems crashed within minutes of each other,
its probably a software problem, so if I don't get the dump, we have ZERO
chance of finding out what happened.) Call the command post for permission to
complete the dump. Denied. Abort the dump. Reboot the primary. Initiate
dump on the alternate. The primary crashes again. Reboot the alternate.
Initiate dump on the primary. The alternate crashes again. This time we get
permission to allow the dumps to complete. Reboot and back on-line. By now,
it's after 0700.

Start analyzing what happened. Trace the problem to a data input routine.
Hmmmmm. Seems like its overrunning the buffer and trashing an adjacent data
structure. Can't be, the buffer is already larger than the physical limit on
the terminal (an IBM 2701 - a then modern but now ancient IBM Selectric
ball-type typewriter rigged as a computer input device). Quick fix: move the
adjacent data structure further away from the buffer, re-assemble (Yes,
Virginia, we had computers before we had compilers. What's that, you little
snot? Yes, I did work on them and no it was not before Christ.), bring the
alternate to "hot backup" status and do a switchover. Take a deep breath and
start figuring out WHY it happened, because the General has missed his Monday
morning briefing and is going to want to know whether he cna count on his
primary command and control system or not.

Hit a stone wall. Couldn't find anything wrong with the code. So I put an
alarm in that input routine, took my chewing out and went on with life. Two
weeks later, my alarm went off. The system didn't crash because I had moved
that fragile data structure, but it would have if I hadn't moved it. The alarm
also triggered an on-line dump and, when I checked it, sure enough, that same
terminal had overrun its buffer again. But it can't! The buffer is 128
characters deep and the IBM 2701 is only 85 characters wide; you HAVE to enter
a carriage return to continue.

Well, not quite. I finally made the connection between one particular Major
inputting data for the General's morning briefing and the alarms. It seems
this Major had figured out that the display screens could handle lines 132
characters long even though the input devices could only provide 85. So when
he got to the end of a line on the terminal, he would grab the typewriter ball,
drag it to the left, manually roll the paper forward and keep typing. As long
as he was entering less than 128 characters, everything was ok. But when he
went over that, ...

OBSERVATION 1: A user will do anything (s)he can think of to get the job done.
OBSERVATION 2: They are usually more creative than we are, i.e., they think of
things we don't.

Jeff Hull, 1544 S. Vaughn Cir, Aurora, CO 80012 303-977-1061 [email protected]

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

Date: Sat, 8 Aug 92 23:27:44 GMT
From: Michael Friedman <[email protected]>
Subject: Re: Bug or Fraud (Kriens, RISKS-13.71)

>... Lewis had put a "conditional statement" in the computer's software
>which caused it to stop functioning at claim number 56789, the judge
>said. The law firm paid another consultant $7,000 to fix the problem.

> [Once again this brings up the concern of people thinking that anything that
> happens in a computer system that wasn't expected by the end users is a bug.
> I'd like a job where I got paid $7000 to remove a "conditional statement."
> John Kriens [email protected]]

I all fairness, let's note that the new consultant was probably expected to vet
the code for any more unexpected surprises. Personally, I think $7,000 was
pretty cheap considering all the ways you can hide a whammy in code.

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

Date: Tue, 11 Aug 1992 14:09:17 GMT
From: [email protected] (Peter da Silva)
Subject: RISKS of DOS, Caller-ID, Voice Mail...

Under (price) pressure, failures certainly become more common:

>Beware of high pressure without passive safety devices!

This is the same problem as our perrenial fly-by-wire discussion, so I'll let
that part of the message stand. I would like, however, to raise another point:

>The pump was controlled by a ZEOS 386 clone via a serial line. [...]

>They had had problems with the clone in the past; most of which were believed
>related to the Extended Memory Manager.

Ah. Doing real-time control under DOS or Windows. I couldn't imagine speccing
a DOS based system for real-time control where system failure could lead to
physical harm. I'm even leary of the use of an AT bus based machine: given
the cost of the rest of the system and the risks involved I'd suggest buying
a professional quality real-time control system rather than using this sort
of hobbyist equipment.

Yes, we use DOS systems as part of real-time control systems, but only for
man-machine interface (monitoring, supervisory control, and so on). And we
typically buy the PC from one of the vendors that sells industrial quality
equipment. Yes, a 19-inch rack-mount passive-backplane box may cost several
times as much as a generic clone, but it's worth it.

If you MUST use a PC, there are real-time systems available: QNX, LynxOS,
iRMX, and so on. iRMX even comes with a Windows-capable compatibility box,
so you can run your DOS and Windows software... though I'd strongly recommend
against it, at least while the experiment is under way.

(note that this is not a panacea: the (presumably professionally implemented)
real-time control system in the pump itself apparently failed as well... but
at least it does give you a fighting chance at producing a reliable system)

===
On another note, I'm concerned about the possibility of "frequent" mistakes
in Southwestern Bell's Caller-ID system. I'm strongly in favor of Caller-ID
as a concept, and have said so here and in TELECOM digest in the past. I did,
however, assume that it would be approximately as reliable as the rest of
the phone system: wrong numbers that are not the result of misdialing are
quite rare. If there's a problem in Call-Return shared by Caller-ID (which
is possible though not obvious: the dialler at the CO that Call-Return uses
might be at fault) then I would certainly want it fixed BEFORE it goes on
line. I'd even support pulling Call-Return until the problem can be resolved.

Pat Townson of TELECOM Digest has apparently seen no signs of this up in
Chicago, so it may be a local problem. Southwestern Bell has not impressed
me with their competance in the past.

===
As for voice-mail systems, a simple "and dial 0 for an operator" entry in
the menu would solve most of the problems people have. I *like* using
these systems, but occasionally I get lost in a maze of twisty little
options (say, for example, the menu item I'm used to selecting has been
changed) and would dearly like the ability to bail out.

Peter da Silva, Taronga Park BBS, Houston, TX +1 713 568 0480/1032

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

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