🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.software.year-2000
Article #22

Re: Chernobyling

#22
From: DEW
Date: Wed, 28 Jan 1998 00:00
128 lines
7410 bytes
Sean Ennis wrote in message ...
>Personaly I think it's mostly the fault of a bad design.  If I recall
>correctly - the Canadian designed reactors (CanDu?) had the benefit of
>shutting down in the even of a catastrophic coolent loss. The

The Candu seems to be designed to fail away from a meltdown although
that doesn't mean that the design is trouble free or even an intelligent to
build on our small planet. It uses heavy water to slow atomic particles that
hit others and create the reaction. When the radioactive heavy water blows
off, the reaction stops.

It reminds me... Years ago I attended a manufacturing software seminar at
IBM. On the way to a washroom, I passed another seminar just as the leader
said, "The message were getting out there is we're number one but we're
not very good."

Candu may be number one because the others are far more dangerous.
You can  find documentation on Candu problems on the web. Candus
create waste that stays deadly for thousands of years (when we've only had
civilizations for 9000?). Candus periodically leak radioactive garbage into
the
air and water around us just like other designs.

>French/American/Russian designs tended not to do do this... infact they
>tended to get much worse.

The state is not reassuring nor is the way people are acting. Where are the
contingency plans to get us by 2000 for these plants? It seems to be too
late for fixes. Who really knows what will happen? Can we do anything to
reduce the risk? Politicians, officials and managers don't want to believe
bad news any more than anyone else.


http://www.house.gov/science/couffou_3-20.html
This site raises some questions. Before the questions it says:

|Software on nuclear sites is subject to stringent quality controls.
|However, |experienced software industry professionals already grappling
|with the Year 2000 have expressed doubts about how reliable these
|design-based reassurances are. Hard and fast test data to back up these
|assurances has not been provided.

There even seems to be good information on how people react.

http://www.csl.sri.com/neumann/neumannSenate.html
|Security Risks in the Emerging Infrastructure
|Here are a few of the many factors that have slowed progress in the
|security of commercially available high-security products -- above
|and beyond the many reasons why complex systems are inherently
|difficult to develop and operate in the first place.
|* The vulnerabilities in the existing infrastructure are poorly
|understood. The risks that can result from those vulnerabilities tend
|to be seriously underestimated. This lack of awareness pervades
|Government, developers, vendors, users, and even bystanders who
|would like to believe that their lives are independent of the technology.
|* Another factor that has slowed progress in security is that, despite
|the very considerable vulnerabilities and risks in today's
|telecommunications infrastructures, digital commerce, and national
|security systems, serious disasters have not yet struck critical
|systems. Major security-related events have not yet occurred that
|in their effects on public awareness might be considered to
|correspond in scope to a Chernobyl, Bhopal, or Exxon Valdez.
|The security-related cases that have occurred have generally not
|caused massive damage or affected many people adversely. The
|1988 Internet Worm, the Citibank penetrations, and a few other
|similar cases are more like the tip of an iceberg. Fortunately, many
|serious security flaws have been detected by friendly people who
|have reported them before those flaws could be exploited.
|People tend not to worry until they have been seriously affected
|(either individually or as part of a nationwide or worldwide effect),
|and by then it may be too late. It is generally unwise to wait until
|after the disaster to plan on what to do. The situation is perhaps
|akin to earthquake preparedness -- you know it is going to
|happen eventually. In this case, the cost of preparedness
|should be chosen commensurate with the consequences
|of the risks that could be avoided.

Do we read this and then just cross our fingers on the nuclear plant/year
2000 software threat. I made an appointment and met with our local federal
representative last week. He thought that the federal industry minister had
everything under control. I showed him the Statistics Canada survey results
and Toronto Star articles pointing out that under 10% of companies had
taken the threat seriously and that his industry minister troubled. The
least
we can do is make leaders aware what can happen. Our local rep will
likely support emergency measures.

>Yah... don't tie/chain control valves in on position (3 Mile) don't do
>f*cking 'experiments' with a comertial reactor (Chernobile(sp?)).

American nuclear reactor personnel still seem to be overriding safety
systems.
http://www.nrc.gov/OPA/gmo/nrarcv/98-05iv.htm

Nuclear Regulatory Commission
Office of Public Affairs -- Region IV
611 Ryan Plaza Drive, Suite 400, Arlington TX 76011
Breck Henderson (Phone: 817/860-8128, E-mail: bwh@nrc.gov

RIV: 98-05 January 16, 1998

NRC, ENTERGY TO DISCUSS APPARENT VIOLATIONS

AT WATERFORD 3 NUCLEAR PLANT

The Nuclear Regulatory Commission staff will hold a predecisional
enforcement conference Friday, January 23, with officials of Entergy
Operations Inc., which operates the Waterford 3 nuclear power plant near
Taft, Louisiana, to discuss apparent violations of NRC requirements.

The conference will begin at 10:30 a.m. at NRC Region IV offices in
Arlington, Texas. The meeting will be open to public observation; NRC
officials will be available afterward for questions.

The apparent violations were identified during an inspection conducted
November 17 through December 5, 1997, and involve mis-operation of a
safety-related cooling system, the auxiliary component cooling water system.
Operators allowed both trains of the system to be inoperable at the same
time and failed to detect and correct the problem for more than seven hours.

>I'm told that it's not 'hard' to shut a reactor down... but it may be a
>bitch to bring her back up (i.e. it could take a couple days).

Three Mile Island  and Chernobyl seems to prove otherwise. Both were hard to
shutdown.

David
Technical Details
Message-ID: <6ank8a$3t4$1@news.bconnex.net>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail
References: <6aiov3$ibt$1@news.bconnex.net> <gUbz.3$Uh1.13072@typhoon.mbnet.mb.ca>

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f504b,89ec2381c18aadad
X-Google-Attributes: gidf504b,public
X-Google-Thread: fc3d0,89ec2381c18aadad
X-Google-Attributes: gidfc3d0,public
X-Google-Thread: f7b9c,89ec2381c18aadad
X-Google-Attributes: gidf7b9c,public
X-Google-Thread: 106cdd,89ec2381c18aadad
X-Google-Attributes: gid106cdd,public
X-Google-Thread: f86b3,89ec2381c18aadad
X-Google-Attributes: gidf86b3,public
X-Google-Thread: f67a2,89ec2381c18aadad
X-Google-Attributes: gidf67a2,public
X-Google-Thread: 112f74,89ec2381c18aadad
X-Google-Attributes: gid112f74,public
From: "DEW" <caper@bconnex.net>
Subject: Re: Chernobyling
Date: 1998/01/28
Message-ID: <6ank8a$3t4$1@news.bconnex.net>
X-Deja-AN: 319990168
References: <6aiov3$ibt$1@news.bconnex.net> <gUbz.3$Uh1.13072@typhoon.mbnet.mb.ca>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Organization: Barrie Connex Inc.
Newsgroups: comp.software.year-2000,can.general,ont.general,ns.general,man.general,ab.general,bc.general