Text File

Subject: RISKS DIGEST 13.72 REPLY-TO: risks@csl.sri.com

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 RISKS@CSL.SRI.COM, 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 RISKS-Request@CSL.SRI.COM.

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 risks-fax@cv.vortex.com).

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: mercuri@grad1.cis.upenn.edu (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 mercuri@gradient.cis.upenn.edu

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

Date: Wed, 12 Aug 92 10:09:31 BST From: Philip Hazel <ph10@cus.cam.ac.uk> 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 P.Hazel@ucs.cam.ac.uk JANET: P.Hazel@uk.ac.cam.ucs +44 223 334714

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

Date: Wed, 12 Aug 92 14:47:43 BST From: Jonathan.Bowen@prg.ox.ac.uk 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, lake@rcwcl1.dnet.bp.com 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: Brian.Randell@newcastle.ac.uk 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 Brian.Randell@newcastle.ac.uk 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) <normdec@vnet.ibm.com> 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: sullivan@geom.umn.edu 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 Sullivan@geom.umn.edu

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

Date: Mon, 10 Aug 92 14:03:24 CDT From: sullivan@geom.umn.edu 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 Sullivan@geom.umn.edu

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

Date: Tue, 11 Aug 92 10:36:07 PDT From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: GAO reports on NASA, the latest from James Paul, paul@nova.house.gov

* 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 (paul@nova.house.gov -- 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: pedregal@cs.umass.edu 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: jhull@muse.den.mmc.com (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 hull@den.mmc.com

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

Date: Sat, 8 Aug 92 23:27:44 GMT From: Michael Friedman <mfriedma@us.oracle.com> 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 jkriens@decoy.cc.bellcore.com]

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: peter@taronga.com (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 ************************