Below is a short article which confirms my suspicions about the RTC problem. It is a bigger issue than just a non-compliant BIOS and any real-time application which directly accesses system time this way is at risk (tons of industrial/engineering apps). ============================================================

August 24, 1998 (Vol. 20, Issue 34)

Scope of Y2K crisis widens: Clock problem found

By Blaise Zerega and Eric Hammond

IT managers testing their Windows NT 4.0 systems for year-2000 compliance have yet another potential stumbling block to overcome: the PC's real-time clock (RTC).

Some Windows NT 4.0 applications, particularly those in time-sensitive usage such as manufacturing and financial systems, directly access PCs' RTCs, many of which are not year-2000 compliant.

In independent analysis, the InfoWorld Test Center found at least one application that accessed the RTC on a PC running NT 4.0. Using Right Time's CMOSView, a system utility, InfoWorld analysts accessed the RTC and found that the year value being read by NT 4.0 was "0000." In a subsequent test, Windows 95 read the same RTC on the same hardware as "2000."

This difference further confuses the testing that IT directors will have to perform and contradicts statements from Microsoft regarding access to the RTC.

"Consistent with programming best practices of not exposing any applications to the real-time clock directly, Windows [NT] 4.0 prohibits applications from directly accessing the real-time clock," according to Microsoft's Web site.

The problem could be severe because most RTCs are not compliant with year-2000 dates; they have only two digits in the year field instead of four digits.

Analysts said it is too soon to estimate how many applications will be affected.

"Many applications go directly to the RTC. The question is, do they have something in place to translate the date and time?" said Karen Moser, director of application development tools at the Aberdeen Group, a consultancy in Boston.

Applications that rely on precise time information -- financial, engineering, and manufacturing -- are frequently written to bypass time information from the operating system and to pull time information from the RTC. This practice ensures accurate information and can improve application performance.

Stuart Greenfield, a systems analyst for the State of Texas in Austin, said he is concerned about RTC access because Texas is building a Web-based tax filing application to run on NT 4.0. A key feature of the tax application will be date-stamping the returns.

Some PC hardware manufacturers have put their users on notice as to the potential for year-2000 problems arising from RTCs. Compaq acknowledged in a white paper that "any application that bypasses the OS and ROM BIOS to obtain data directly from the RTC may receive an incorrect date."

To resolve this problem, Microsoft suggested that companies redirect time-sensitive applications to a source other than the RTC.

"A good time source is typically a network time service [NT 4.0 resource kit and NT 5.0 built-in] pointed at a standard such as the Navy observatory time service, which continually supplies accurate time," said Jeff Price, Microsoft lead product manager for NT Server, in Redmond, Wash.

But applications that interpret noncompliant RTCs may be thrown off by this solution or even by buying a new PC.

"People are in a catch-22. If you get a server with a compliant RTC, then what do your applications do?" Greenfield said.

Ephraim Schwartz contributed to this article. Other applications that access the RTC may include word processing documents and spreadsheets.

Copyright (c) 1998 InfoWorld Media Group Inc.

-- R. D..Herring (drherr@erols.com), September 25, 1998

Answers

For a similar article, see also http://www.infoworld.com/cgi-bin/displayStory.pl?98095.ehrtc.htm

-- Joe (shar@pei.com), September 25, 1998.

Microsoft says: "...Windows [NT] 4.0 prohibits applications from directly accessing the real-time clock..."

I wonder what they mean by "prohibits." Since they didn't say "prevents," maybe they just made up a rule...which of course, no one would be forced to abide by. It sounds like MS made a statement that isn't grounded in fact. This is just another bit of bad news to add to the growing list...

Speaking of Microsoft, do they keep adding more Y2K fixes to their site? I was downloading patches and printing web pages (gotta have that hard copy) today, and it seems like they have more stuff posted than when I was there a couple of months ago.

Thanks for the post, R.D.

-- Mike (gartner@execpc.com), September 25, 1998.

(R.D., bear with this reply please -- )

Okay, let's reread that article. I just did, twice. And the only concrete laboratory-type evidence that is documented in the article is that "in independent analysis, the InfoWorld Test Center found at least one application that accessed the RTC on a PC running NT 4.0."

At least one. If it was definitely any more than one, they would have said that, so in essence they found one. One (1).

The rest of the 'data' in the article is opinion or unsubstantiated feeling, without supportive data; reminiscent of the "cautious optimism" of the NERC report the other day, except that this is in the pessimistic direction. But the same danger exists here: conclusions without firm concrete evidence.

Folks, we need to watch out for groupthink, either false-positive or false-negative. The NERC report the other day was an example of false-positive groupthink. We get too many reports that are full of "might", "may", "could", "potential".

I want to hear "is", "is not", "will", "will not", "definitely", "has been proven". For good or bad. False-negative conclusions are just as bad as false-positive. Neither are the truth.

R.D., not trying to dis ya man; just playing the fly in the ointment. I respect your credentials and intellect out the yingyang. Let's think real good & hard about this here thing. (Like we aren't already, huh LOL)

-- John Howard (Greenville, NC) (pcdir@prodigy.net), September 26, 1998.

Good comments by Mike and John, but lets look again at the article and the subject (gee, sounds like English class!!). NT 4.0 does not prohibit RTC access in the sense of a software barrier. They are just saying programmers SHOULDN'T do it. But in certain scientific or engineering apps (say a chemical plant mixing vat) realtime speed control is very important. The chemical engineers will impress that on the pale, trembling programmer. The programmer will then employ every ounce of his meager intellect to make his process control run as fast as possible. Ah HAA he cries," if I directly access the RTC in the timing section, I can save 100 milliseconds per valve actuation AND I can send telemetry data to the main host at the same time." Been there and done that with a very similiar app for a specialty steel plant!! Microsoft says in the article to use an outside time reference. The problem is that for some realtime apps that may be to slow in terms of internal access.

Yeah, it looks like MS keeps adding stuff to their web page for Y2K fixes.

I don't know about online DEC RTC resources but will look.

John - I agree it is important to not over read some of these things. But, you only need one instance of an event to prove it exists. InfoWorld could not have looked at very many NT systems in total. Yet they came up with an example which, when closely examined, was in error. I am emphasizing this RTC area because I feel that it is a critical subject in many industrial applications. Process control computers often sit between the 'intelligent tool' and the main host computer. In a refinery for example you may have info/control links: (valves with embedded sensors)<---> process control <--> Host Applications for process control are written to be as efficient as possible. I'm certain there are a lot of 386 and 486 based process controllers out there. If there are widespread industrial failures, it will probably be because of these and not so much the main host.

Hmmm, time to order more food and a Armalite M15A2.

-- R. D..Herring (drherr@erols.com), September 26, 1998.

This goes along with the news that some Federal agencies are accepting on Y2K compliant RTCs in their new desktops. Too bad they didn't start that a couple of years ago. (Not finger-pointing, just too bad.) The type of thing R.D. is talking about will become more of a problem in the future, unless everyone specs out total compliance. Our top Controls Engineer was telling me that in the food and beverage industry, the trend is away from separate PLCs and toward centralized control with a PC. They could have this same type of problem, especially as line speeds continue to increase. It amazes me how fast they fill beer and soda bottles! And there isn't a shrink-wrapped program for these types of system controls, so programmers are free to fall into the non-compliant RTC trap. Especially if a PC manufacturer claims Y2K compliance, when what they mean is a compliant BIOS/RTC combination.

-- Mike (gartner@execpc.com), September 26, 1998.

Once again R.D., I should let the engineers stick to their engineering huh!

See what you mean about the difference between 'prohibit' and 'prevent'. And the 'need for speed' (of course that's paramount in Corporate Anywhere).

And yeah, where there's one, there are probably others...though who knows how many. (We all hope not many, of course)

Guess I should listen to me ownself type more often too....posted a quote over on that other 'Y2K quotes' thread the other day, quote by H.L. Mencken: "The public....demands certainties...But there are no certainties." Guess that's especially true with Y2K reporting; but it's still something on my wish list. (^_^)

-- John Howard (Greenville, NC) (pcdir@prodigy.net), September 28, 1998.