IEEE: Without a coordinated international effort, global electronic infrastructure is at severe risk of collapse. There has been no such effort!

greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread

Category: Compliance

Date: 1999-09-29 05:18:05

Subject: IEEE Uses the Word Collapse; Then It Backs Off to Middle of Road. Warning: Problem Will Last for Years.

Link: http://www.ieee.org/organizations/tab/Y2kFocus_tisrel11...

Comment: The Institute of Electrical and Electronics Engineers published a document on July 30, 1999. It speaks of a possible collapse.

Without a coordinated international effort to investigate, review, disseminate and promulgate practical, shareable, standardized problem descriptions and solutions, it is arguable that the current interconnective complexity of the global electronic infrastructure is at severe risk of collapse.

I am unaware of any "coordinated international effort to investigate, review, disseminate and promulgate practical, shareable, standardized problem descriptions and solutions." I am unaware of any such national program.

Then the document goes on to dismiss the concerns of survivalists.

The stakes being what they are, I recommend survivalism.

This may be one of the most important paragraphs in any y2k document:

These issues, although important, are dwarfed by the Y2K problems inherent in the vast accumulated base of data in files and databases all over the world that must be processed by application software, software that may not know how to resolve the ambiguity caused by the missing century digits in year representations in that data. Those issues are rooted in many programs needing to compute on data that has at least two dates, each on a different side of the 1999/2000 boundary. This is true whether it is now in 1999 and the program must deal with another date in or beyond 2000, or it is now in or beyond 2000 and the program must also deal with another date back in the 1900s; it is true regardless of when now is. . . . For every non-PC computer clock involved, there are millions of data records. For the one-time rollover of system clocks there are astronomically countless times data records with potentially ambiguous century representations must be properly processed. While the rollover effect will happen in a moment and dissipate relatively quickly, data processing errors are happening and accelerating now and will go on for years after the rollover. Impacts may peak in the early weeks and months of 2000, when todays date is on the new side of the boundary, but they are not by any means confined to that period.

So, when your y2k-skeptical friends come to you on January 1 to say that everything is just fine after all, you are in big trouble . . . because your friends can still find you.

Being good engineers, they search for quantitative estimates of the effects of y2k. They resort to the famous bell-shaped curve. They forgot to mention the obvious: the fractional reserve banking system. When banks cannot settle with each other, there are cascading cross defaults. Then there is no bell-shaped curve. There is a universal economic shut-down. The day we can't pay each other, the division of labor will collapse.

* * * * * * * * * * * * *

In their unremediated state, a significant percentage of the world's digital systems, computers and information infrastructures will begin to operate unpredictably or fail completely on or before January 1st, 2000. This situation has been imprecisely called the Millennium Bug or Bomb  more precisely but inaccurately the Year 2000, Y2K or Century-Date-Change crisis, and, (most recently and correctly), the Century-Digits-Change or CDC problem 1 .

A superficially trivial issue, the omission of the century digits from dates, has created computational ambiguities that first corrupt individual systems and then propagate to endanger interrelated systems and entire organizations. To discover, identify, isolate and correct every date-related operation within each individual system is challenging in itself; to integrate, coordinate, synchronize and validate all changes across the web of interconnected systems and organizations is the most daunting task our community has ever faced. Without a coordinated international effort to investigate, review, disseminate and promulgate practical, shareable, standardized problem descriptions and solutions, it is arguable that the current interconnective complexity of the global electronic infrastructure is at severe risk of collapse.

The Y2K crisis presents a significant challenge to society on a global scale. It is neither as dire as some pessimists and survivalists believe, nor as simple and innocuous as optimists believe. It will directly or indirectly affect everyone on the planet (although not in ways generally conveyed by the media), and one way or another everyone will be involved in resolving and recovering from it.

This unsettling scenario is the reluctantly reached but carefully considered conclusion of a range of responsible researchers  from system theorists to financial analysts to economists (p. 1). . . .

There will be failures of computer-based systems, especially those rich with complex software and interconnections to other systems; even if all such systems could be made to be Y2K compliant (itself a highly improbable occurrence), they will not necessarily all be compliant in the same way and so will lose some of their effective connectivity. This is especially true across organizational boundaries, where remediation control and responsibility are ambiguous. These interconnection failures will be just as dangerous as individual system failures, if not more so, as they have a better chance of cascading to yet other systems (p. 2). . . .

[The Federal Reserve System, the world's most important central bank, has over 316,000 interconnections. The FED is connnected to the world banking system, which has no standardized approaxch to compliance.]

Inherent in the above is the fact that the Y2K crisis is only incidentally about the year 2000 or time in any here-and-now calendar sense. The implied instantaneousness of the term Millennium Bomb, all of the celebrated count-down clocks, the anxiety surrounding the rollover at midnight of December 1999  and even the term Y2K itself  all relate to the relatively minor clock issues, more solvable problems of hardware and low-level software. These issues, although important, are dwarfed by the Y2K problems inherent in the vast accumulated base of data in files and databases all over the world that must be processed by application software, software that may not know how to resolve the ambiguity caused by the missing century digits in year representations in that data. Those issues are rooted in many programs needing to compute on data that has at least two dates, each on a different side of the 1999/2000 boundary. This is true whether it is now in 1999 and the program must deal with another date in or beyond 2000, or it is now in or beyond 2000 and the program must also deal with another date back in the 1900s; it is true regardless of when now is. (Programs or systems that are concerned only with the current year and a future year will only have problems until 2000 begins. After that, if they keep their two-digit year representations, they will be fine. Programs or systems that are concerned only with the current year will have no problems at all, even without modification. This is one reason many physical controller units will have no, or only short-duration clock-hiccup, Y2K problems.) For every non-PC computer clock involved, there are millions of data records. For the one-time rollover of system clocks there are astronomically countless times data records with potentially ambiguous century representations must be properly processed. While the rollover effect will happen in a moment and dissipate relatively quickly, data processing errors are happening and accelerating now and will go on for years after the rollover. Impacts may peak in the early weeks and months of 2000, when todays date is on the new side of the boundary, but they are not by any means confined to that period (p. 3).

-- The Programmer (The Programmer@code.com), September 29, 1999

Answers

Just 28 workdays 'till Turkey Day. NOTHING gets accomplished in December.

Don't worry, be happy.



-- K. Stevens (kstevens@ It's ALL going away in January.com), September 29, 1999.


1. the link should be: http://www.ieee.org/organizations/tab/Y2kFocus_tisrel11.PDF

2. The text of the opening post of this thread appears to be copied from Gary North's site without attribution and without the italics by which Gary indicates references to the IEEE document.

Jerry

-- Jerry B (skeptic76@erols.com), September 29, 1999.


We don't have to worry about embedded chips. Flint and Y2K Pro (Schmo) will fix them all during the rollover weekend. We all just know in our heart that fix on failure will work.

-- Mr. Adequate (mr@adequate.com), September 29, 1999.

Please post the origination point of the pdf file without posting the .pdf. In other words, get as close as you can to the window with the document on it, but only post the address to get to the document. Thank you.

-- OR (orwelliator@biosys.net), September 30, 1999.

Moderation questions? read the FAQ