1) My name was on the same line as Yourdon's
2) There's a good statement in the middle that says that
Bill Gates was observed inspecting uninhabited Palmyra Atoll, for
possible purchase. I guess they are intimating
a) he will wait out the y2k problems there (don't fly up to
6 months beforehand, Bill, or
b) he wants to be like Marlon Brando and own his own
island and is oblivious to any y2k threat.
3) Something I didn't know about y2k: Programmers
focused on the two-digit date concept, or ignorant of the precise
definition of the functionality of "tm_year", developed their
applications to use the output as if it was always two-digits.
While true that in year 1998 it will return to the
application "98", in 2003 it will return "103".
Greg
------- Forwarded Message
Message-ID: <3556581B.8A4E5610@ica.net>
Date: Sun, 10 May 1998 21:45:01 -0400
From: Gary Allan Halonen <njarc@ica.net>
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: Barry Walker <bjw01@ibm.net>,
Dave from Marietta <goldey@atl.mindspring.com>,
Dolby <dolbydunn@poboxes.com>, Ed Yardeni <yardeni@ix.netcom.com>,
Ed Yourdon <ed@yourdon.com>, Greg Bolcer <gbolcer@ics.uci.edu>,
"Howard, Dan: CIO" <Howard.Dan@ic.gc.ca>,
Jennifer Yourdon <jennifer@yourdon.com>,
Kate Mitchell <trailblz@scscomm.com>, Ken Larson <kglarson@ix.netcom.com>,
"Ken R." <ksr@ptc.com>, Martyn Emery <101464.664@compuserve.com>,
Maverick <riverrat@fgi.net>, Norm Kurland <kurlandn@crisny.org>,
Peter de Jager <pdejager@year2000.com>,
"rcowles@waterw.com" <rcowles@waterw.com>,
Roleigh Martin <Roleigh.Martin-1@tc.umn.edu>,
Toni Nash <ToniNash@compuserve.com>
Subject: Harlan Smith Proposal
Content-Type: multipart/mixed; boundary="------------763224EAC153CF76225E9C15"
This is a multi-part message in MIME format.
- --------------763224EAC153CF76225E9C15
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Greetings,
Retired computer specialists, Harlan Smith, in conjunction with other
computer experts, has put together a comprehensive, brilliant Y2K
Mitigation And Contingency Plan which if widely known and implemented,
may save us all a good deal of hardship and heartache in the coming
millennium.
The idea is to get this Plan really out there. Perhaps put it on the
table at the upcoming G8 Conference and get Federal governments
implementing the Plan before it's too late.
Please put the Proposal on your web sites. Attach the Plan to your
email list with a suggestion they copy and pass it on to their contacts.
Post it to your forums and ng's so everyone even remotely working with
Y2K issues are aware of the Proposal.
Send it off to your Members of Parliament, Congresspersons, Senators
and Leaders with an introductory note. Let's get it out there,
circulated around and seriously considered then worked on. We have this
great tool of internet technology to use to forward ideas which will
eventually effect everyone in the world.
Personally, I for one, am tired of hearing only bad news and scenarios
of Y2K doom. I can't stress enough how important Mr. Smith's Proposal
may turn us back from the iceberg, if and only IF acted upon in time.
Please do your part. Thank you.
Gary Allan Halonen
------- Begin of Forwarded Message
1998-05-10 -- 4-part Article - "Synergistic Mitigation and Contingency
Preparation"
[Note on 1998-05-17] The underlying concept of this proposal is to focus
mitigation resources on an "Austere Infrastructure" that would be sufficient
to minimally support our populations and provide a robust repair base for
those elements of our infrastructure that fail as a result of the calendar
"rollover" to 2000-01-01. This concept acknowledges the fact that a full
remediation effort is perceived to require more expenditure of effort than
can reasonably be accomplished in the 593 total working and non-working
days, prior to 2000-01-01.
The Perceived Y2K Threat -
and the Disabilities of the Current Approach for Responding to that Threat
Nearly all elements of the global infrastructure are immensely threatened by
calendar rollover from 1999-12-31 to 2000-01-01, for the following two basic
reasons:
1. "Brittleness of Infrastructure" -- Because computers have made it
possible to implement cost-competitive innovations to our
infrastructure elements in a very exaggerated manner, our global
infrastructure has evolved to become immensely "brittle" and computer
dependent. Examples of both this brittleness and excessive computer
dependence are:
a. Oil production and delivery extensively dependent on "embedded
systems". Oil rigs thought to have large numbers of "embedded
systems" in difficult-to-access locations and assessment of the
problem is apparently proceeding at an unsatisfactory pace.
b. A USA electric power grid that is vulnerable to complete
disruption by local overloads or failures of individual generating
stations. Both transmission grid and generating stations are very
dependent on computers and "embedded systems" and assessment of
the "embedded systems" problem was revealed in the just-completed
EPRI (Electric Power Research Institute) conference in Dallas to
be only at 10%. (Failure example, Auckland NZ central business
district recently without power for 3 month period).
c. JIT (Just in Time) deliveries of component parts to automobile
manufacturing plants depend heavily on computers, thousands of
2nd, 3rd, 4th tier suppliers and very tenuous and vulnerable
supply paths across international boundaries. (Failure examples,
tests run by General Motors and Chrysler corporation.)
d. Computer dependence and long supply lines in the "Food
generation and distribution" chain.
e. USA Railroad dependence on computers and "embedded systems" for
train operation, signaling and switching. Signaling and switching
vulnerable to any local power failure along a transportation path.
Manual switching of RR cars precluded as RR switchyards have been
torn down and replaced with computer-controlled distributed
switching on sidings distributed geographically throughout the
entire network. (Failure example recent prolonged problems
experienced by Union Pacific.)
f. Immense dependence of airline operations on FAA air traffic
control, airport systems dependent on computers and "embedded
systems", airline systems and, to a lesser degree, aircraft
systems. (Failure example, Denver airport which, even though
"new", is again at risk from Y2K problems.). Planned evolution
from radar controlled "air corridors" to GPS navigation, allowing
"free flight" for increased capacity, thwarted by recent discovery
that GPS is very susceptible to even inadvertent jamming.
g. Federal Agency computer systems in dire straits, prominently
including IRS, Treasury, Department of Defense, Department of
Energy.
h. Many state governments lagging badly and city/county
governments still in awareness stage.
2. Defective programming practices embedded in the culture of computer
programming -- There are several date-related computer program defects,
pervasively distributed throughout all of our infrastructures. Either
of these will cause computers using "date-sensitive" software, to
malfunction, as manifested by generation of bad data or abrupt
cessation of data processing. The two most prevalent defects are:
a. Two-digit Year - An almost universal, 40-year-old, computer
programmer practice of representing the calendar year as two digits,
prefaced by an assumed "19". This will cause the computer application
to interpret a 2000 year input from the computer operating systems as
"1900" and date calculations based on this spurious information will
cause malfunction of the application software. In a "best case" the
computer will halt operations and in a "worst case" it will generate
bad data that can propagate widely via computer networks to corrupt
databases in large numbers of computers.
b. Mis-use of date functions - An almost equally serious problem
involves the computer programmer mis-use of the output of a computer
function known as "tm_year", when designing application software. This
is an insidious problem, as this function returns to the application
"years - 1900". Programmers focused on the two-digit date concept, or
ignorant of the precise definition of the functionality of "tm_year",
developed their applications to use the output as if it was always
two-digits. While true that in year 1998 it will return to the
application "98", in 2003 it will return "103". This will cause the
application, designed to accept a two-digit year, to experience field
overflows or other problems and malfunction. This kind of problem is
prevalent in programs written in the very popular, "C", Java,
JavaScript, Perl and other similar languages. At least two analogous
functions in IBM mainframe software can be similarly mis-used to
produce similar malfunctions.
3. The defects exist in very large numbers throughout the following kinds
of systems. "Remediation" involves modification, updating or
replacement of the "operating systems" and "application software" and
in some cases this correction is blocked until the computer hardware is
replaced with a later design, as the effort to support and upgrade
software for the older "platforms" has been abandoned.
a. Mainframe computers, largely running COBOL [Co(mmon)
B(usiness-)O(riented) L(anguage).]programs, that form the backbone of
our business, financial and other elements of our computer
infrastructure.
b. Midrange computers that exist in large numbers providing basic
computer services to small and medium-sized business enterprises.
(Often, the only viable remediation path is to replace both computer
hardware and software.)
c. Client/Server systems that may require replacement or updating of
server operating system, networking software and application software
running on the client "workstations" (usually PCs --Personal Computers)
d. Embedded Systems, that are said to exist in quantities on the order
of 25 billion and, even if only 1/10 percent of these are susceptible
to malfunction due to software defects, that presents the problem of
very tediously rooting out and correcting 250,000 problems. Since the
assessment of this problem, and its quantification, is so exceedingly
tedious it remains essentially unquantified and therefore the number of
problems distributed throughout the global infrastructure may be 2.5
million or more. Infrastructure elements such as automated factories,
chemical plans and oil refineries, electric power generation and
transmission, oil rigs and any other places where computer automation
is prevalent are highly susceptible to having massive "embedded
systems" problem.
4. Implementation of the 5-step "remediation" process [1) Awareness, 2)
Inventory, 3) Remediation, 4) Testing, 5) Implementation]. has proved
to be very difficult, time-consuming and costly for the following
reasons.
a. The nature and scope of the Y2K problem can only be accurately
understood by assimilating a large number of "clues" and making
inferences. The general population does not have the time or
inclination to educate themselves via this involved and tedious
process, nor has the press been so inclined before publishing
"debunking" articles, based on little or no study of the phenomena.
Only very recently has the Y2K story been successfully communicated to
an entire local community.
b. Prominent scientists, economists, investment advisers and news
reporters have also failed to experience the tedious Y2K education
process and consequently make public debunking statements, promoting
complacency rather than awareness among the general public. Casper
Weinberger, chairman of Forbes magazine, has editorialized regarding
his serious concern about Y2K, yet his apparently schizophrenic
organization allows his writers to publish deleterious debunking
articles.
c. With the very-recent exception of Arthur Gross, chairman of Intel,
officers of our prominent computer software and hardware manufacturers
have not publicly manifested any concern about the Y2K problem. Bill
Gates has only belatedly pursued issues relating to Microsoft software
and has been observed inspecting uninhabited Palmyra Atoll, for
possible purchase.
a. Assessment of computer software and "embedded systems" problems is
still underway. US Air Force inventory/assessment was supposed to be
complete last June and still is not complete. The very-recent EPRI
conference indicated that assessment of electric generating stations is
only 10% complete. The GAO is collecting State data and will issue a
report. City/County government status is largely unknown. There is no
good overview for the medium and small business. Assessment status of
"embedded systems" on oil rigs and the oil delivery system is not
visible.
b. Modifications multiply the lines of code to remediate -The scoped size
of the problem does not seem to completely comprehend the fact that
programs of very substantial size have proliferated into multiple
customized forms that can no longer be remediated once for all users.
Every customized instance of the program tends to become a new program
derivative that must be remediated separately from its base program of
origin. In essence, this means that there is far more software to be
remediated than could ever have been generated by the programmers who
wrote the original software. The number of lines of code to be
remediated in fact tends to be multiplied by the number of separate
instances of modification. Source code is often lost, with only the
operating object code remaining. Reconstructing source code from object
code is usually more difficult than writing new program modules.
a. "Embedded Systems" - Remediation of "embedded systems" is often a task
that must be accomplished by a team of engineers, technicians and
programmers. Special test equipment must be available to run advanced
clock tests as the systems in general do not have keyboards and
displays. Obscure languages and software compilers are often used. The
source code for the application may be lost. Once the code is
remediated the "embedded system" must be tested. Then the remediated
software may have to be programmed into some kind of ROM (Read Only
Memory) chip. The ROM may have been mask programmed as part of the
manufacturing process, programmed on a test set by blowing fusible
links (ROM), erased with ultraviolet light and electrically
reprogrammed (EPROM), or taken to another kind of equipment for
electrical programming (EEPROM). A repair action must occur to replace
the reprogrammed part. Then, system level testing must be accomplished
to make sure that the revised software functions properly in the system
environment.
b. PC Applications - It is not generally understood that the much
advertised PC Clock problem is the least of the problems in the PC
arena. Both IBM compatibles and Macintosh computers suffer problems
with their very numerous applications. These are the same two-digit
year problems experienced by mainframe programs plus the very insidious
"tm_year" problem that has not been mentioned at all in the popular
press.
a. Remediation of mainframe software and setting up additional computers
to do "advanced clock" testing of remediated software has proved to be
a difficult, but extremely necessary multi-faceted task. Preparation
involves not only setting up redundant hardware but, upgrading
operating system software and arranging for special software licenses
that will not show expiration when the system clock is advanced.
b. Before remediated software is subjected to advanced clock testing to
prove its Year 2000 compatibility, it must undergo thorough "regression
testing" to prove that the original functionality of the non-compliant
software is preserved. While a well organized IT operation will
maintain a library of updated regression tests, often this regression
testing software is mis-placed or not up to date. So even when only a
small percentage of the code has been changed, test code must be
written or revised to provide the capability to test the entire
functionality.
a. Synchronized implementation of communicating partners - Rarely, if
ever, discussed in the press is the fact that, when communicating
partners change the format of the information they communicate, they
must synchronize their transition to the new interface. In general, Y2K
remediated software will replace a two-digit year interface to
communicating partners with a four-digit year interface. This is done
because it is necessary to make sure that the data received is
unambiguously interpreted. For an expedient simplification of his
remediation task, a communicating partner may indeed retain two-digit
years internal to his calculations. Two digit years imply a limited
span of valid years, such as 1950 - 2050 or 1970-2030. A so-called
software bridge is constructed to send and receive data, so that a
4-digit year interface is presented. The communicating partner may then
carry a 4-digit year internally or build his own bridge compatible with
a two-digit 100 year window that may be different from that of his
communicating partner.
"Synergistic Mitigation and Contingency Preparation" -
A Method of Efficiently Addressing the Perceived Threat -
The underlying concept of this proposal is to focus mitigation resources on
an "Austere Infrastructure" that would be sufficient to minimally support
our populations and provide a robust repair base for those elements of our
infrastructure that fail as a result of the calendar "rollover" to
2000-01-01. This concept acknowledges the fact that the remediation effort
is perceived to require more expenditure of effort than can reasonably be
accomplished in the 593 total days remaining before 1999-12-31, at the
1998-05-17 conclusion of the G8 conference.
The implementation of the "Austere Infrastructure" concept will require a
highly-focused and globally collaborative effort, guided by information
obtained from high-level modeling and simulations of critical elements of
the infrastructure. It must commence with the deep involvement of University
researchers, skilled in the arts of "Operational Analysis", "System
Modeling" and "Simulation". It must be an interdisciplinary effort with
contributions from experts in all critical infrastructure elements that
would be the constituents of the core group comprising the "Austere
Infrastructure".
The impossible task of completely remediating the entire computer
infrastructure prior to 1999-12-31 will be replaced with the doable task of
mitigating the elements of the infrastructure needed to support world
population. A strong focus on "mitigation of an austere infrastructure" will
clearly present a picture to the public that world governments have
appropriately diverted their focus and effectively concentrated the
application of resources to aggressively head off the potential for
disaster. This will allay public panic, boost morale of those engaged in the
mitigation effort and encourage support from the entire global community. It
is a practical approach that will allay public panic.
The high-level steps in the process for identifying the elements of the
proposed "Austere Infrastructure" and enhancing their survivability through
the rollover are:
a. Operations Analysis effort to identify, configure and model an
"austere infrastructure" and explore methods of enhancing its Y2K
survivability.
b. "Global Triage" to strip down to an "austere infrastructure",
which inherently will have greater probability of Y2K survival
than the total existing infrastructure.
c. Identify interdependencies in the "austere infrastructure" that
can perhaps be removed to make it more "Y2K survivable". Modify
the "austere infrastructure" to remove these unnecessary
interdependencies.
d. Using the model, explore survivability enhancements, such as
upgrading to more reliable components, adding redundancy,
reconfiguration, reducing functionality to necessary minimum.
Emphasize robustness of critical support utilities such as
petroleum supply, electric energy and telecommunications.
e. Implement the stripped-down and reliability-enhanced "austere
infrastructure" and then test it for Y2K survivability as
possible, Supplement the test data with continued exercise of the
model(s). (The necessary extreme focus on this minimum "austere
infrastructure" will require that additions to the computer
infrastructure, such as the pending transition to the "Euro"
currency be deferred until the critical transition is safely
passed.)
f. Undertake an effort to implement contingency backups, at
multiple levels, for each critical element of the "austere
infrastructure" to further enhance the probability that the
overall "austere infrastructure" will survive the Y2K transition
period. (However long.)
g. Expand the modeling effort to analyze the capability of the
"austere infrastructure" to form a robust base for repairing and
restoring elements of the overall infrastructure that may _not
survive the Y2K transition period intact.
The Perils of the Present Full Remediation Approach
Full Remediation is at High Risk of Failure, Leading us to Individual
Survivalism
The reasons I strenuously object to the ideas of "individual survivalism"
and "safe haven alarmism" are as follows:
* It focuses on abandonment of cities. Cities are not viable without the
utility, communication, transportation etc. infrastructures remaining
viable. A city without a very complex supporting infrastructure cannot
function as a city or perhaps function to support even a small part of
its normal population.
* This then implies that huge populations must move from the city to the
country. While perhaps possible, this would be an immense logistics
challenge. It is not an option at all in Europe.
* Without countrywide coordination, that could only be accomplished by
the Federal Government and a lot of intense preparation, this concept
could never work for the majority of our population. Grass roots
efforts, although worthy, will just not move fast enough to cover more
than a fraction of the population.
* It ignores the fact that our present populations depend on a
highly-computer-dependent "food generation" capability, that would also
have to be replaced with something very different, also creating huge
logistics problems. Possible but not likely.
* It ignores the fact that if cities are abandoned and the teaming hordes
flee to the countryside, there will be no safe haven anywhere in the
continental US.
* It ignores the fact that all of us, and particularly those with serious
medical problems, are very dependent on sophisticated medical care and
abandonment of our utility infrastructure will pull the rug out from
underneath our ability to maintain the capability to provide this care.
* It ignores the problem of providing medicines and drugs to those
dependent on them for survival and/or quality of life.
* It does not provide a good recovery base in terms of utilities,
personnel and complete repair/remediation environment to restore our
infrastructure.
* It prematurely focuses on "contingency measures" (which are bordering
on an OXYMORON with regard to Y2K) as opposed to "mitigation" which is
where almost all of our energies should right now be concentrated.
* Simply stated:
* Remediation - repair it, so it will continue to function as it does
now. We don't have time to complete this project.
* Mitigation - find weak spots and modify the infrastructure to be less
brittle and more resistant to failure. Provide substitutes for elements
of our infrastructure most likely to fail. (FEMA equivalent -- move
populations out of the flood plane)
* Contingency Preparation - develop backup capability that will be used
when the normal infrastructure breaks (FEMA equivalent - feed, clothe,
house people after they are flooded out.)
* It ignores the fact that we must maintain a robust economy and military
infrastructure to maintain protection from foreign predators.
* It ignores the fact that we have built a Pandora's Box of nuclear,
chemical and biological hazard sites and only the presence of a vital
infrastructure keeps the lid on that box. We have set ourselves up for
this and we are stuck with it.
We're locked into maintaining some good semblance of our present
infrastructure. Without precluding contingency preparation, the majority of
our energies should be focused on "Mitigation" as that will be the easiest
and most feasible method of sustaining our population and providing a
recovery base to build back to our present infrastructure capabilities.
We could dispense with a lot of frills for 2 or 3 years or however long it
takes, but we can't turn our back on our infrastructure. We need a
well-orchestrated, intensely-cooperative effort applied to "mitigation".
Fleeing to the countryside is not a viable solution for the majority and
likely not a solution for anyone.
Expected Benefits of Changing Course to -
"Synergistic Mitigation and Contingency Preparation"
1. Emphasizes application of intellectual resources (operations
analysis modeling) to optimize probability of achieving limited
goals.
2. Capitalizes on good ideas expressed by others such as "Global
Triage" and "Y2K Czar"
3. Highly-effective conservation of resources, by tight focus on
remediation and reliability enhancement of limited set of
infrastructure constituents.
4. Several complementary features (minimal complexity, redundancy,
upgraded reliability of infrastructure elements.)
5. Highest probability of sustaining total population and
preserving repair base.
Cuts the "contingency preparedness" problem down to manageable proportions,
as we will not have to provide backup for failure of all elements of the
infrastructure, a clearly impossible task.
A highly coordinated effectively-led global attempt at "Synergistic
Mitigation and Contingency Preparation" seems to be our only hope to
implement a prolonged recovery from the Y2K menace.
------- End of Forwarded Message