Hi,

I have heard of a test at a utility in Australia where supposedly they set the time ahead to 1/1/2000, and everything "shut-down". They kept trying, but could not get things to come back up.

Is there something about embedded controllers that allow time to be set forward, but not back?

It sure would be nice if a worst-case scenario for the utilities was "just" to set the clocks back. I have looked for discussion and white-papers on this but either they were vauge, or too technical for me to understand...

-- Phil (pperucci@mindspring.com), June 10, 1998

Answers

Phil,

First, some embedded systems have their programs, including date settings (if any) burned in to read-only memory. These can't be changed, and must be replaced.

Second, if embedded systems cause a shutdown, simply setting the dates back at that time won't completely restore the plant to pre-test configuration. Why? Because the power shutdown is not due to the fact that the system reads 2000..........it's due to events that are logged after the clock roll over. Perhaps a pressure or temperature reading is out of tolerance, so the normal 'fail-safe' is to shut down the operation.

Third, you're looking for a 'silver bullet'-----"just set the clocks back and nothing will happen." Hey, fine, you set the clocks back in one embedded system that can be accessed, but now it reads a drastically different time than a system in which the date is burned in. So, now you have problems because the two systems in the same plant are on different pages. 'There is NO silver bullet.

-- Rocky Knolls (rknolls@hotmail.com), June 11, 1998.

<>

This isn't necessarily an embedded issue. If a system can be accessed well enough to change the clock in one direction, it can most likely be changed in the other.

However, there are all sorts of problems companies have encountered in the course of Y2K-testing, including some which would never have happened in 2000 itself, but were a direct result of testing methodology.

For instance: one of the biggest "issues" of Y2K-compliancy is a system's ability to process events/records/transactions/whatever in non-sequential order. For instance, to handle the following events in the order presented:

Jan 1 1998: Event A

Jan 10 1998: Event B

Jan 5 1998: Event C

Many systems assume that events A-B-C can only occur in chronological order. Thus, if a system date rolls over from 99 to 00, the events could occur in non-sequential order (ie, 98 - 99 - 00 - 01).

However, THIS IS EXACTLY THE PROBLEM SOME COMPANIES CREATE when they try to use "roll-forward" testing. They're sailing along quite happily in 1998, decide to test their system for December 1999, let it rollover to January 2000, and are pleased to find no problems resulting. (Meanwhile, systems may actually be storing records, logging events, etc.) THEN THEY ROLL THE CLOCK BACK TO 1998, and what happens? Suddenly--as a result of improper testing, not Y2K itself--they start logging events from 1998 again, after they'd already logged events from 1999 and 2000.

BAM! You have a situation that some systems can't handle, even systems WHICH WOULD HAVE HAD NO PROBLEM PROCESSING 1998 - 1999 - 2000.

That's one type of problem.

Another type is especially prevalent in Unix environments, where background "cron" (scheduled) jobs are often built into servers to automate administrative tasks. For instance, a "cron" program might be set to automatically delete any files which haven't been accessed in more than 2 years, figuring that nobody wants them anymore, or that the data is no longer current and should have already been replaced by 2 years-worth of more-current data.

In the course of testing, you roll the clock forward and...in the background, at the system level, some of those forgotten cron jobs quietly wake up, notice that you have a lot of obsolete data laying around, and promptly delete it all for you! (This has happened to several firms.)

That's another type of pitfall.

In conclusion, then, there are all sorts of "interesting" effects you can get from rolling your clock forward and back, quite removed from any actual Year-2000 bugs which may

-- Mark Zieg (mzieg@orlandosentinel.com), June 11, 1998.