[CURRENT Y2K THINKING]
This is a very well written message from Harlan Smith. It sums up a lot of current NEW thinking on Y2K:
- focus on electric utilities
- focus on supply chaing issues and circular dependencies (i.e. utilities depend on railroads that depend on utilities).
- focus on forgotten UNIX/C y2k issue 'TM_YEAR'.
- focus on mitigation
Highly recommended!!
John
______________
From:
ourworld.compuserve.com
'Date: Sunday, 3 May 1998 11:08:30 -0500
From: Harlan Smith hwsmith@cris.com
Subject: Sharing my World - "Synergistic Mitigation and
Contingency Preparation", Embedded Systems and tm_year
Roleigh et al,
MY BACKGROUND
I wish I could tell you about the kinds of things I worked (I can
talk about some of the lesser, now de-classified systems)
because the many-year design process was very interesting
(to me, anyway). We started with a handful of people who
were on the receiving end of some very interesting scientific
research that sought to capitalize on a fairly obscure physical
phenomena. So we had to brainstorm how we might build a
system to capitalize on that effect and then build very
complex models/simulations to convince ourselves that we
might build something that would work and how we could
optimize design parameters to make it work better.
Then we would launch into an iterative process of
modeling/simulation and building test systems. Information
from the models influenced the topology/parameters of the
tests systems and, conversely, information from the test
systems was fed back into the models to make them behave
more like real systems. In order to get from here to there, we
relied on both extensively. Many people distrust any kind of
modeling or simulation, for which there is some basis in fact,
but if a model/simulation helps get the job done then one
can't say its not useful.
Were these efforts successful? Yes, we clearly achieved our
objectives and the efforts continue on well beyond my
retirement. Is it deployed to the field and will it ever be used?
If we need it for national defense. You probably realize that it
is this kind of effort that yields the advanced systems that
allow us to protect our interests in manners such as winning
the "Gulf Conflict". I believe that the knowledge I have gained
in these kinds of efforts prepare me to think productively
about and effectively address some of the more difficult
aspects of Y2K.
On the human side, I have 5 left-handed children (really!), 4
daughters and a son, all college educated. The daughters
live with 7 grandchildren in the Dallas area. Unfortunately, my
wife of 39 years passed away in 1992. The son has an EE
degree plus a Master's in computer systems. This gave him
an excellent background to work on the same kind of systems
that I worked on. He has bounced all over the country for the
last 12 years or so, chasing the big buck as a contract
programmer. His specialty for many years was the "Ada"
programming language which was designed specifically for
real-time control systems and BTW is used to implement the
Canadian Air Traffic Control System, which I believe is
somewhat technologically advanced from our
currently-fielded FAA systems.
My son Michael worked on many of the systems used in
"Operation Desert Storm", including the MLRS (Multiple
Launch Rocket System), Apache Helicopter, P3
Anti-Submarine Warfare aircraft, and a long time on the
M1-A2 tank. (M1-A1 was used in the gulf war). His transition
from the cold war environment was to the SAP ERP
(Enterprise Resource Planning) tool and the unique
programming language associated with that tool. It is the
modern replacement for the COBOL relied on so heavily by
large companies. SAP, is not a panacea and cannot be easily
transitioned to, but has the attribute of greatly improved
programmer productivity over COBOL. My son can do in days
with SAP what it might take weeks to accomplish in COBOL.
It is too late now for a company to start replacing a major
COBOL system with a SAP system, but I can probably point
you to a large number of companies that wished to hell they
had had the prescience to do that.
Michael has worked SAP at Adobe Software in CA and an
18-month stint at Microsoft in Redmond, WA, ending
Christmas 1997. He then moved to work for a major oil
company as a contract SAP programmer in Fairfax VA. He
has attended the Washington DC Y2K user's group meetings
and other Y2K meetings in the Washington DC area. He
wrote a report of Jim Lord's presentation at George
Washington University and it was immediately published by
Adam Kaplan on the Westergaard site as the e-mail message
"Dear Dad" y2ktimebomb.com
Opinion/Readers/hsmth9813.htm
I spend a lot of time on news:comp.software.year-2000. It's
like sorting through a garbage heap, that also happens to be
a mine field, but there are some _very Y2K knowledgeable
people there and once you learn the cast of characters you
can (with great difficulty) get a very accurate perspective of
what is occurring in the Y2K world. One can also extract
nuggets of Y2K information not available elsewhere. It is
mostly populated with, and ruled by, mainframe programmers,
but I am tolerated and recognized there for my unique
contributions and hopefully sometimes for my unique insights.
I _try to work with many individuals and groups, including
being an Associate Sysop on CompuServe GO YEAR2000
and a member of CPSR (Computer Professionals for Social
Responsibility) - Y2K Working Group
cpsr.org.
CURRENT Y2K INTERESTS - Embedded Systems, tm_year
and "Synergistic Mitigation and Contingency Preparation",
The current focus of my Y2K efforts hopefully is matched to
my unique talents, skills, knowledge and perspective to
address the following areas:
1. "Embedded Systems" Problem-- An extremely important,
very much misunderstood area. It is often labeled as a
unfounded fear because reporters deviate from reality by
talking about microwaves, elevators and coffee pots where
the problem doesn't really exist and ignore industrial
processes where it can have such effects as crippling the oil
industry and shutting down all GM manufacturing plants.
It is often labeled by the complete misnomer "embedded
chips". "Embedded systems" are aggregations of computer
chips that perform a computer-like function and are
vulnerable to Y2K phenomena, due to designed-in "date
sensitivity" which often, but not always, manifest a Y2K
problem due to an improperly programmed calendar function.
They are called "embedded systems" because they are not
packaged in a box identifiable as a computer.
The misnomer "embedded chips", leads to a further
misunderstanding called the "non-compliant chip". There are
none such because all Y2K phenomena are software related
and exist because of a flaw in the software, not the hardware.
The confusion may arise because the software for an
embedded system may be programmed into a ROM (Read
Only Memory) chip, of one of several types. Usually, the
"embedded systems" manufacturer/designer loads the
software into some kind of PROM (programmable read only
vendor) but sometimes, for high volume applications he might
request the semiconductor manufacturer to supply a "mask
programmable" part that builds the customer's software right
into the delivered part.
The bottom line is that the "embedded systems" problem is
very serious, it is not a hardware problem but a software
problem, the problem is created by flawed software written by
or for the "embedded systems" designer, it is never caused
by the semiconductor manufacturer. A survey of such will
reveal that none will have ever shipped (to their knowledge) a
"non-compliant chip". It is not useful to talk about either
"embedded chips" or "non-compliant chips" because those
terms are very mis-leading. [End of Sermon]
2. The "tm_year" and "SVC-11, TIME" functions -- These are
important Y2K problems that are well known to astute
programmers, but have not at all surfaced in the press. The
"tm_year" problem relates to several popular languages used
with Windows and Unix operating systems, and the very
similar "SVC-11, TIME" function problem relates to IBM
mainframes. The "tm_year" function, and the problem related
thereto, exists in the very popular "C", "Java", "Javascript",
"Perl" and other languages. It is used by the application
programmer to go to the operating system and get a current
year. The current year is returned as "year -1900"
Now here is where the problem comes in. Some manuals
have mis-communicated to the programmer that the output
was a two-digit representation of the current year, so 1998
would be 98 and 2003 would return 03. The programmer
would then have designed his code to work with a two-digit
representation of the current year. But, tm_year returns "year
- 1900". Now, in 1998, it will return the expected 98, but in
2003 it will return the unplanned for 103. This likely will cause
the program to provide bad data or program halt due to an
overflow condition.
This problem is insidious because it is separate, distinct from,
and in addition to, the commonly understood and discussed
two-digit year date ambiguity problem. A program can be
subjected to complete remediation for the two-digit year
problem (by either of the popular "date expansion" or "date
windowing" methods) and still fail advanced-clock (time
machine) testing due to the presence of a mis-use of tm_year
problem. It can affect programs that only get the date from the
operating system for the purposes of date/time stamping and
do no date-based calculations at all. Such applications are
unlikely to be purposely subjected to advanced-clock testing
because they are thought to be intrinsically immune to Y2K
disruption, due to this absence of date-based calculations. I
have a long list of applications that exhibit this defect, some
of them written by Microsoft.
The bottom line is that we have another, somewhat hidden,
Y2K problem that must be added to our remediation and
worry lists. It affects PCs, Unix servers and its "SVC-11"
counterpart affects IBM mainframes. It also can affect
"embedded systems".
3. Synergistic Mitigation and Contingency Preparation -- This
is my personal thrust to most productively use our available
resources to protect us from the ravages of Y2K. Simply
stated, mitigation I define to be any of a large number of
things we can do to _prevent a Y2K phenomena from
breaking a _critical element of our infrastructure.
Complementary to mitigation is contingency preparation
which can provide a backup for an element of the
infrastructure that suffers a Y2K disruption. The two can and
should be synergistic, working together in a complementary
way at many levels.
The mitigation efforts I plan to propose recognize the fact that
Y2K is not caused only by Y2K problems (two-digit year,
tm_year and other failures) but perhaps more importantly the
unplanned and very unfortunate 'brittleness" of our
infrastructure. This "brittleness" is caused by many attributes
of our infrastructure introduced because we could do them,
not because they were the wisest things to do. These things
include, reliance on massive interdependent computer
systems for almost any activity, long tenuous transportation
paths involved in any industrial activity, JIT (Just in Time)
manufacturing concept, reliance on "embedded systems"
and/or computers for almost any modern control function etc.
Let's take an example to see how mitigation and contingency
preparation can work together, for us to solve a particular
problem. You (Roleigh) have expressed a significant concern
that Minnesota electric utilities rely on coal-fired generating
stations and the coal must travel across several states to
reach these stations. Railroad signaling and switching relies
on electrical power supplied locally. So any interruption of
electric power along the route may thwart the delivery of coal
to the Minnesota electric generating stations and Minnesota
will go dark and cold. In a normal situation, we could rely on
the power grid to stand in for the absence of local generating
capability, but it would be foolhardy to rely on such in a Y2K
scenario.
As you (Roleigh Martin), suggest, a resource-economizing
"contingency preparation" for keeping Minnesotans warm in
January would be to procure a wood stove and wood supply
for every fourth house. So, if the power and heat failed, then
the 4 families could huddle together and stay warm with
minimum consumption of critical resources (the wood pile).
[Webmaster's note: the above paragraph responds to my
proposed fallback plan for taking care of the heat issue if
power is out for a prolonged period of time in Minnesota in
2000. With the every fourth house proposal, there would be
enough houses for those living in apartments--the
consolidation of people should be done on a voluntary basis
aided perhaps with tax incentives, individual households
could decide differently. I am not in favor of a police state
approach to attacking this problem. I am in favor of a
community having a fallback plan for a worse case year 2000
situation.]
We than should complement this "contingency preparation"
with a mitigation effort. That effort would target the brittleness
of the RR delivered coal function. One of the first things one
could do is spot generators along the RR delivery path to
maintain the capability for RR signaling and switching during
local power outages anywhere between the coal sources and
Minnesota. This was attempted during the Quebec winter
storm problem but the generators were stolen, so they would
likely have to protected sufficiently to divert the thieves to
more vulnerable sources of such equipment.
Assuming that the above example at least partially explains
my idea of " Synergistic Mitigation and Contingency
Preparation" I will explain how we can press the approach
hard to provide a general level of protection from Y2K. Let's
first extend the concept to our entire power grid.
There are 9000 electric utilities, 108 nuclear generators and
122,000 substations and switching yards involved in
supplying power to the continental US. Most of these are
vulnerable to one kind of Y2K failure or another. There is
much brittleness associated with this overall power grid
configuration. It appears that only Texas can split off
gracefully if other portions of the grid or generating capacity
begin to fail.
It is my specific proposal that we should call on (no _mobilize)
the Colleges of Engineering at our various universities to
involve those individuals skilled in the discipline of
"Operations Research". They should be tasked with an effort
to collect massive amounts of data on the nature and scope
of this power grid problem, construct models and simulations
of elements of the power grid as feasible in the short time
frame and provide the following outputs from that effort:
a) Guidance and recommendations for mitigation efforts to
regulatory authorities, such as PUCs/PSCs and NRC.
b) Similar guidance to electric utility organizations and their
technical organizations such as IEEE, EPRI, EEI.
c) Function as a collection point and reservoir of information
useful for mitigation and contingency preparation and/or
guide the efforts of other organizations to perform those
functions.
d) Recommendations for focusing resources to most
effectively mitigate the threats to the supply of electric power
in any way possible. This could involve more effective
remediation and testing techniques, prioritization of activities,
recommendations for removing unnecessary dependencies
etc.
e) Develop and communicate, to all those concerned, a
quantitative overview of the total problem, so it will be clear
where resources should be applied for maximum benefit to
the power grid. (I don't want to slight any power user but it
essential to maintain the power grid, so that we will maintain
a capability to rescue those deprived of electric energy. A
downed power grid is a disaster in many ways for everyone.)
f) Use the same information base developed above to focus
contingency preparations in those geographical areas judged
to be most vulnerable to loss of electric power at critical
times.
4. Next areas of focus for "Synergistic Mitigation and
Contingency Preparation"
a) Food generation and distribution
b) Healthcare infrastructure
c) Telecommunications
d) Energy supplies
e) Minimum financial infrastructure
f) Others as prioritized.
------------
Comments are welcome and encouraged.
Harlan Smith |
