Mr. CEO's cancellation

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

Don't even know correct e mail address for posting in this forum.Have been a level 6-7 doomer for the last year because of firsthand knowledge of IV&V results on cobol sent to India and Ireland(more errrors than when it waas sent). Anyway, always thought that we could extricate ourselves from our self created mire if infrastructure held,but am now among those who seriously doubt this is the case. Would suggest that Jim Lord, having smacked this hornets nest with a stick should, at least use the Gary North-D.D. Reed 'ask her' format to provide us with some useful information from Mr. CEO. Get specific on DAB's, accessibility of systems, secondary clocks(is this a real issue?) failure rate observed to this point and extrapolations, verification and clarification of the 40-60% figure. This addresses Mr. CEO's fear of identification and informs those of us who have been following the issue closely.

-- Gregory Arthur Fey (gaf@mindspring.com), November 26, 1999

Answers

Mr. Fey - I would like to address your concern about the applicability of considering the importance of secondary clocks.

To understand the importance I will use a 'real-world' example of which you might have some familiarity. The clocking system of the computer sitting in front of you.

Your system, if it is like most, has a BIOS subroutine that enables you to reset the real-time clock on the motherboard of that computer. The input you provide the BIOS routine is a form of primary clock. It provides a start reference point akin to "At the tone, the time will be...!" In almost all other applications of importance to the y2k issue ... telcom, power, and other utilities; military systems; satellites; etc ... the primary clock consists of an electromagnetic signal emanating from the National Institute of Standards and Technology on the Ground Positioning Satellite System. Just like entering the wrong date/time onto your BIOS configuration, an erroneous date/time signal from NIST will result in an erroneous time stored in affected systems.

The next level in the clocking hierarchy, the secondary clock, would include such circuitry as the real-time, or hardware, clock itself in your system. Everytime the secondary clock circuit initializes, it recovers the stored values of current date and time from the original primary input and adds the elapsed time since that input. The secondary clock then outputs the 'corrected' current date/time to the working, or tertiary, clock. For MOST systems, the secondary clock is what provides the continuous definition of current date/time to the hardware and core operating system.

Finally, in your computer is what is commonly referred to as the Software clock ... which is the tertiary clock. This is used by application software for maintaining current date/time when running those applications. This clock is nothing more than a software subroutine that keeps a continous count of elapsed time and adds that to the value of the secondary clock when the software application was initialized. Problem here is that the subroutine uses the timing chain provided by the secondary clock as a means of keeping track of time intervals to determine that elapsed time.

Y2K has the POTENTIAL of creating the following problems in clock/timing circuits:

a) GPS glitches - so does the entire continuum of systems utilizing it for primary clock and timing information.

b) If the BIOS is not compliant - the secondary clock may lose the date/time input from the primary clock and/or it may not run at the correct rate.

In the first case, the system hardware may either not initialize at all or it may fail at the start of the operating system, resulting in the 'blue screen of death'. Either way, the result is an obviously dead system.

In the second case, one error that might result will probably be that system timing can become compromised resulting in a system error shut-down. The timing chain upon which the entire system depends becomes scrambled. The operating and/or hardware systems lock up and the system operator will have to reboot. All application software data entered from the time the timing chain started to glitch until the system locks up will most likely be lost. Note: this condition could also lead to the demise of circuit boards and/or components in the system due to additive effects of timing pulse overvoltages burning out microcircuit components that have a clock input. Overlapping voltages on the clock bus are additive, like batteries in series.

The other scenario is perhaps the most insidious of all - application software would be initialized with an erroneous intialization date/time. The software may a suffer an obvious error and shut down or worse, continue to operate using that faulty date/time info.

Conclusion: The secondary clock is VERY important ... it is the heart of the system ... everything is derived from, and depends upon, the accurate initialization and operation of the secondary clock.

-- hiding in plain (sight@edge. of no-where), November 26, 1999.


Hiding- Thanks for the informative post. You have just explained a world of info to me. I know about mechanical things, but only know enough about this contraption in front of me to turn it on and surf the net a little. I can't link, or post or anything you experts can do. I come to this site to read info just like what you just wrote. Thanks again.

-- dozerdoctor (dozerdoc@yahoo.com), November 26, 1999.

You are most entirely welcome DozerDoctor ... Tis a pleasure to help others. :-)

We each have our areas of expertise ... and can help many.

Everyone is important. Even those pesky Trolls ... Why without the lowly cockaroach, all life would soon expire - fouled in our own waste!

Hmmm ... is he saying what I think he's saying? LoL

Good thing I'm hiding in plain sight! Heeheehee

-- hiding in plain (sight@edge. of no-where), November 26, 1999.


BTW: You don't have to be insane to work here ... but it helps!

If people think you're crazy, they tend to leave you alone.

:-) Hint to survival!

-- hiding in plain (sight@edge. of no-where), November 26, 1999.


Moderation questions? read the FAQ