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…
In the 1880's the Canadian Pacific Railway wanted a line between Montreal and Toronto but could neither afford to build one nor to buy out an existing railway. So what they did was to take a perpetual lease on an existing railway, the Ontario and Quebec. Later they did buy up O&Q stock until they held 80% of it. Along with the O&Q came land in Toronto and Montreal that is now of great value. Over the years the CPR sold off this land. Finally someone noticed that they didn't really own it, bought up some O&Q shares, and brought suit against the CPR. The case was appealed to the Supreme Court of Canada. Just before the court decision the O&Q shares were valued at $15,000 (Can.) each. A ruling for the O&Q would likely raise that by a factor of 10 or more -- and a ruling for the CPR would drop it by a factor of 10 or more! The court ruled for the CPR, and the stock dropped $14,100 per share in one day (and more the next day). But there was no entry in the stock market columns for this remarkable change (the stock was listed as not traded). According to the Toronto Star, "a Toronto Stock Exchange computer interpreted the sharp drop reported by stockbrokers as an error".
From the June 30 Edition of the San Diego Union:
PacBell's Service is Disrupted:
Computer glitch snarls multitude of 619 area calls
A computer program glitch disrupted telephone service in San Diego and
Imperial Counties for several hours yesterday, potentially affecting all 1.1
million Pacific Bell customers in the two-county area. The breakdown came
on the busiest workday of the year's busiest telephone season. A major
malfunction in the computerized switching equipment at the company's main
station in Hillcrest prevented many long-distance calls from going through
the 619 area code, Pacific Bell spokesmen said. Affected were both local
and long-distance toll calls.
Pacific bell noticed calls backing up on its monitor at around 9:30 AM.
By late afternoon, technicians had traced the problem to a mysterious
foul-up in the programs — the only part of the enormous computer, installed
in 1984 and working since without a hitch, that has been updated frequently,
a company spokesman said. The system was shut down at 10:56 AM for 152
seconds — a record. Then the computer had to be reloaded, trunk line by
trunk line, while the search continued for the problem. By 6 PM, most of
the system was back in service.
(The story goes on to describe the local impact, especially on the
long-distance companies who weren't at fault.)
>From: Eugene Miya N. <eugene@ames-pioneer.arpa> [RISKS-5.5] >NASA has established a voluntary, confidential safety reporting system ... For many years, NASA has operated the Aviation Safety Reporting System (ASRS) for the FAA. It has been quite successful, producing important information about flight safety. The ASRS has two key features to encourage participation: immunity and confidentiality. When someone reports an incident to the ASRS, he/she gains immunity from FAA disciplinary action for inadvertent errors associated with it (deliberate actions are not protected). NASA ensures confidentiality by separating the identifying information from the report during initial processing. The reporter receives a numbered receipt which can be used to prove that he/she reported the incident to ASRS. Without the receipt, the reporter cannot be identified. The ASRS works because it offers an inducement for reporting (immunity), and provides reliable confidentiality. It probably helps that the program is operated by a trusted, independent agency.
The notion that the proposed access charges for enhanced service providers represents some kind of "information tax" seems to be remarkably popular. Of course, it's total nonsense. The FCC is merely suggesting that Tymnet, Telenet, etc. no longer be exempt from the access charges that all other services (e.g., long distance voice) must pay for connection to the local telephone network. The original exemption was to protect a "fledgling industry." Whether the industry can now compete on an equal basis with AT&T and MCI remains to be seen. The computer-related risk here seems to be in how easy it is to forget that our networks are being heavily subsidized by both private and public money. joe
RISKS-5.5 reprinted part of a newspaper story: Boston (AP) - "A computer problem that blanked the radar screens of air traffic controllers from New England to the Great Lakes for six minutes delayed flights at Logan International Airport, but posed no hazard, an official said.... This is at best vague and pointlessly inflammatory; at worst it's nonsense. The key question is: was more than one installation affected? What exactly does "from New England to the Great Lakes" mean? If they mean more than one site, how could that have happened? Are ATC computers networked together in such a way that a crash can propagate? (I doubt it; as I understand it they're too old to know about things like networks). If not networks, then perhaps it was a common mode power failure. At sites several hundred miles apart? I doubt it. If more than one site, then why were only the Logan flights delayed? How exactly could more than one site be affected at the same time and for the same duration? And in what conceivable sense was it "a computer problem"? A common mode software bug? One that bit all the places at the same instant? It's considerably more likely that what they really meant was something like "One computer failed today for six minutes at Logan airport." Presumably the longer-range radar at Logan tracks some flights as far as Lake Ontario (about 500 mi). It's also possible that there are ATC centers in Montreal, Toronto, Buffalo, Detroit, New York, Cleveland, Columbus, etc. etc., (all within the same 500 mi. range) that were capable of tracking those flights, in addition to the backup system mentioned in the story. It's also interesting that there's still sufficient flexibility in the ATC system that simply slowing things down handled the problem. The problem is that "One air traffic control system halted for six minutes today at Logan airport" and "it didn't matter at all," just isn't much of a story. Not nearly anxiety producing enough; not nearly technophobic. Imagine the same story written with a slightly different viewpoint: "The reliability of our rather old ATC system was demonstrated today when the system at Logan airport failed completely for six minutes. Even though flites as far as 500 miles away were affected, the problem was easily handled by the existing procedures for slowing down some flights and keeping others on the ground, made possible by the routine use of backup communication systems designed for this purpose." There are as I understand it abundant problems in getting ATC done right, ranging from reliable sw and hw to reliable organizations of people and alignment of responsibilities. It's best we attend to the real problems and try to discourage nonsense like this. Tell your local newspaper they really do have to get the facts correct. [You can always tell a newspaper man, but you can't tell him much! PGN]
The airmiss was allegedly due to the display equipment not showing details of an aircraft because it had a duplicate SSR transponder code... But aircraft without an assigned code all have the same code (1234 in UK, 1200(?) in US); similarly emergency traffic all uses a small number of not-guaranteed-unique codes; so this can't be the entire explanation... (one hopes!)
The following letter is from the syndicated column by advice-giver Ann
Landers, which I saw in the 1 July 1987 (Providence, RI) *Journal*.
Though it addresses real RISKs concerns, I include it more for its
giggle value.
PHONE COMPANY GIVES SOMETHING FOR NOTHING
Dear Ann,
I think I can top the person who wrote complaining about the idiocy of the
phone company. Talk about garbage in, garbage out!
When AT&T split with Bell, we had three phones in our house. The equipment
belonged to Ma Bell and the service belonged to AT&T. After we returned all
the phone equipment to Ma Bell, we received a bill for $0.00. A few weeks
later, we received a check for $5 and a note thanking us. Several months
later, we received another computerized bill for $0.00. We called again,
got nowhere, so we sent another check for $0.00. A few weeks later we
received another $5 refund with the same thank you.
This went on every three months for two years. Now we are down to once a
year and have given up trying to straighten this out. We just cash the $5
and forget about it.
— Linda K. R. in California
Stephen W. Thompson, User Services Specialist, User Services
Brown U., Box P, Providence, RI 02912 USA Smile!
THOMPSON%BROWNVM@WISCVM.WISC.EDU (401) 863-3619
Here's something to chew on.
%T DOD Gives Software Developers More Leeway In Writing Code
%J Electronics
%V 60
%N 12
%P 99
%D June 11, 1987
%O Military/Aerospace Newsletter (department)
%K SDS 2167/A Top-Down Methodology Waiver
%X Military contractors no longer will be forced to use top-down methodology --
in which design and coding of computer programs use a hierarchical structure --
when developing software for the Department of Defense. The Pentagon has
revised its two-year-old Defense System Software Development Standard,
designated 2167, and will issue the new version, 2167/A, on June 30. The
document spells out what the DOD expects from software contractors and gives
them more leeway in writing code than the original standard. Although the
DOD revised 2167 in response to industry dissatisfaction with the standard,
some software suppliers are calling for further changes, such as provisions
for rapid prototyping. Howard L. Yudkin, president of the Software
Productivity Consortium, a Reston, Va., group respresenting 14 aerospace
companies, is pushing for an industry position on where and how to use and
not use 2167. The DOD, he says, should "recognize Standard 2167 as good for
the engineering development phase for which it was intended, but not for
advanced development." The Pentagon's Computer Software Management Subgroup,
the joint-services committee responsible for 2167 revisions and compliance,
believes that 2167 coverage of rapid prototyping is premature, according to
Air Force Capt. Rick Schmidt, committee chairman.
%X That is the entirety of the announcement. Having not seen the revised
standard (and not being a follower of the original, for that matter), I can't
ascertain whether this is a dangerous situation or not. But it reminds me
that the reputation of the Go To is being restored in the letters sections
of Communications of the ACM, also.
— Dennis E. Hamilton
Please report problems with the web pages to the maintainer