FactFinders Y2k List

There are way too many questions and challenges in the "Which is it?" thread to address each one of them, so I will just go for the highlights. Since I am so late joining the thread, I will start a new one.

As usual, I will use extensive use of a numbered list, a trait that is indicative of conservatives in general. If you are a liberal, please feel free to mentally substitute literary paragraphs for the numbered list. If libertarian, or better yet, survivalist, feel free to replace the numbers with bullets :)

1. This is the most intelligent and articulated forum I have seen on the Internet concerning Y2K issues. Period. Even those not directly involved in the utility industry are knowledgeable and challenging.

2. Rule of conduct - After reading the posts of the last week, I see a need to modify the way I post information, and hereby resolve to share information and avoid confrontation. As several of you here have quoted, "Blessed are the peacemakers...". I have been afforded anonymity here which I need since I am currently directly involved in the utility industry, however I have misused this privilege a bit. Also, Frautshi has asked that he be contacted directly for comments on his paper, and I think that this is only fair and will not comment further in the forum, nor will I comment on the recently posted lookalike paper. I would be more than happy, however to discuss any embedded system failure claim in detail, regardless of where the claim originated. It's embedded systems that we should discuss, not whether individuals are right or wrong. (Although feel free to take your swipes at me if it makes ya feel better ;)

3. CL is bearing the brunt of the load in trying to answer everyone's questions, and is doing a great job of giving a different viewpoint from a utility insider's perspective, and should be thanked for at least giving you the other side of the story for your consideration. I honestly wish I had more time to provide information.

4. Being prepared with a few days worth of supplies for any emergency is in my opinion a good idea. No one should be ridiculed for this, it's just good common sense. What I take issue with are those who advocate extreme measures based on massive and long term power outages due to y2k. I heard one of these guys on the radio just last night discussing Y2K- the interviewer was talking to a guy from a company that sold a years work of food package. This is just a plain old rip-off by placing fear in the minds of the unsuspecting. I lost power for a week during an ice storm two years ago and our regular weekly stock of groceries did just fine. My personal preparations for Y2K are to get a loaf of bread and a gallon of milk a few days before the end of the year before the rush begins :)

5. I have never said that there are no Y2K bugs that could shut down a power plant, in fact I do believe that I have said that there could be a bug somewhere that could shut a plant down. What I have said is that I have not found any problems with the nuclear plants that I have been involved with that would have directly caused a plant shutdown due to a y2k bug in the control systems or control equipment. I also said that this was consistent with what I have heard from my peers in the industry and those who have attended the EPRI conferences. There is an important point here - plant shutdowns due to serious y2k bugs should be much, much rarer that the early predictions that were given by many, since the actual findings in the industry indicate that y2k bugs are usually minor in nature. There have been reports in the press that indicate that there may have been problems found that could shutdown a plant - I do not know whether this reports are valid or exaggeration, but I do know enough about how Y2K is being reported to suggest that such reports be verified directly with the engineers and technicians involved in testing. I do sincerely believe that there will be no significant effects of y2k on the ability of the country to supply power, based on what we are finding in the utility industry and what I have learned in research in the areas of transportation, oil, and other infrastructure. I truly believe that I will be able to turn on my PC and come to this forum on Jan. 1 2000 and say "see?" ;)

6. Y2k bugs ARE being found in the power industry, and lots of them, in both embedded systems and software. In fact, here is where I am in disagreement with some of my associates. In the cases of equipment/devices with date functions ( a very very small percentage of a typical inventory), I have found a fairly high Y2k bug rate (my guestimate is 20-50 % for equipment with date functions, in the utility industry). Keep in mind that most devices do NOT have a date function. My findings in software (I have assessed a lot of applications) are similar. Basically, IF it has a date, the chances of it having a Y2K bug are fairly high. HOWEVER, as stated in 3 above however, these bugs are mostly minor problems such as incorrect dates on screens and reports. In some cases, devices and software have y2k bugs that cause moderate problems such as trending graphics screens that do not work properly on the X axis (date). It is a very rare to find a device that totally fails or causes bad data (other than date data). Why are we spending so much time and money on fixing minor problems? We don't like to have bugs in our software, our hardware, or anywhere else. Also, I would hope that the fact that we are correcting even minor y2k bugs would help to increase the public confidence.

7. The government, NEI, EPRI, the NRC, and each utility are all doing an extremely poor job of getting out to the public hard examples of what we are finding. I would like to give you manufacturers, model numbers, descriptions of the Y2k bugs. I am considering writing a paper on findings at the current plant I am at and encouraging management to release these findings to the public, without the legal filtering that is killing the openness we need on this important issue. I would appreciate any comments and suggestions in this regard.

8. I have already done a post in this forum somewhere on Allen Bradley PLCs, complete with links to the minor y2k bugs that a few of them have but which will not prevent the PLCs from operating and should not cause any problems. I would also suggest looking closely at the custom written application program for any PLC's with real time clocks, to see if the program uses dates in a way that could cause a problem due to any operating system bugs identified by the manufacturer or in testing.

9. PC hardware Y2K bugs are way overblown as well. Yes, most PC's made prior to 1997 are not compliant, and a lot made in 1998 are not compliant and will not automatically rollover on the real time clock while they are shutdown. However, the untold story is the vast majority of these can be manually set for January 1, 2000 and from then on will hold the correct date. For home PCs I don't even recommend flashing the BIOS to make the rollover work - why risk a bad BIOS upgrade problem when you can manually set the date? (By the way, even the ones that cannot be manually set will continue to run, just with the wrong date - the crashing PCs was just another one of those wonderful Y2K myths). Windows 3.1, Win 95, and NT4.0 are all basically Y2k ready, the dates will work properly. There are a few minor issues such as the filemanager in Win 3.1 (the only problem here is that the file date will be foobar ";0" or ":0" (I can't remember which) for the year 2000 instead of "00" (I believe windows explorer in Win95 has the same problem, but please verify) - you can fix these with patches from the Microsoft web site. I have done this and it works fine. The y2k bugs in PCs that are of major concern are in the applications that use dates in important ways .

10. The facts aren't always on the surface, and as far as Y2K goes, I have found that they are several layers deep. The normal "two source rule" that journalist use just isn't good enough with Y2k if you really want the facts.

Regards, FactFinder

Shopping Hint - Wait until after January 1, 2000 to get an excellent deals on secondhand, but never used, backup electric generators ;)

-- Anonymous, March 01, 1999

Answers

Fact Finder, thank you for your posts. Your influence is not minor. My question relates to utility progress.

It is clear that the number of problems being found with embedded systems is less that originally anticiapated. Why then do we have so many utilities that won't be through with there remediation and testing until this summer or fall? Are they working on low priority fixes, like the ones you describe, instead doing important testing?

-- Anonymous, March 02, 1999

Factfinder,

Two points. One, you left out perhaps the most important Y2K statement of all, one which I almost require to hear from someone before I will take them seriously, and that is this, or words to this effect:

"I do not have all the answers. In fact, you should not take my word for anything."

When I speak publicly, I usually start with the line, "I'm not a Y2K expert, but I play one on TV." (the audience laughs- or I shoot them :) "The reason I say I'm not a Y2K expert is because there is no such thing as a Y2K expert. It's simply impossible." Etc.

One of the things that impressed me the most one of the first times I came to the euy2k site was a line Rick had on the home page which said "What do you think? Am I way off base?" I knew that was a sincere sentiment on his part, and it told me he was humble in his views (and, besides, anyone who looks at the potential problems from Y2K has to think of themselves that they're nuts).

Second, re the "two source" rule. Let's not mix politics and Y2K, so to speak, since the "two source" rule was at minimum emphasized during Watergate. As someone who has pounded this beat more than anyone (with the possible exception of Declan McCullagh), I can tell you that getting people to talk about this, particularly on the record, can be just nuts. In some sectors, it's not too bad. But I have had Y2K experts, sources, whatever you want to call them, tell me some, shall we say, extraordinarily interesting things- off the record. I can sometimes use that information without attribution, sometimes not at all.

This is further complicated by the fact that tech types- whether EEs, programmers, or whatever, do not always agree on things beyond the most incontrovertible facts. Thus, trying to get two sources for anything but the most violently elementary information can be difficult, ie, when you get beyond the basics and into the area of what might potentially happen under Y2K circumstances. For that matter, I've had lawyers disagree with even the basic reality that lawyers are keeping information bottled up (something de Jager just wrote about- I posted it tonight). Get into any sector of Y2K, and you'll find disagreements. Not about everything, of course, but about a lot.

I have written some exceptionally pointed memos to our staff in times past on facts. In fact (so to speak), my own definition of facts come from an old SF story about a man with a robot servant. While demonstrating the android to a friend one day, he remarked that the robot told only the truth. How so, his friend inquired.

"What color is that house on the hill over there?" the man asked his servant.

"It's white on this side," the android replied.

I've never forgotten that story. It's white - *on*this*side*. When I speak publicly, I sometimes hold up a white coffee cup and ask the audience what color the cup is. I point out to them that it's white- on the outside. On the inside, it's navy blue.

Y2K is like that: it may appear to be one way, but until we get more facts, it might actually be something else. And getting those facts in this particular area of study can be miiiiiiighty difficult. One reason why: the facts vary from case to case, sometimes from embedded system to embedded system.

I could go on & on about this, but it *is* 1:12 in the morning, and everyone tells me I work too hard as it is :)

-- Anonymous, March 02, 1999

PS: I agree, this is probably the most literate forum on the Net. In part, I would guess, is because it is specialized.

And also, to this day, I know of at least one person inside one of the most prepared power companies in the country - who still wants to buy a generator.

-- Anonymous, March 02, 1999

Okay, I'm going to take a chance on looking like a dummy here. F.F., one thing that isn't addressed in your post (btw, I appreciated it and found it informative and helpful to even me a "civilian"). But I live near Austin, and my coop gets its power from LCRA who uses coal to generate 60% of it's electricity. This coal comes from a little town in South Texas who gets it from two sources in Wyoming. Posted on the TEXAS y2k info page is a ? about railroads, and the answer leaves us thinking there may be a problem getting that much coal here in a timely manner due to the R.R.'s y2k issues (which we won't go into here). My point is that it does bother me some that this issue isn't usually considered when deciding whether to prepare for problems.

Secondly, (and this may be another thread; shoot, I may be knitting an entire sweater here, I'm not sure), but I read an article posted on the Yahoo y2k News site yesterday which came from "The Nation", I assume a semi-monthly publication. Here are some quotes from that article:

"NIRS executive director Michael Mariotte warned, 'The unpredictablility of how systems may respond to Y2K bugs, questions of the reliability of off-site emergency responders, including telecommunications, fire, police and other officials, all beg for additional training and practice."

The article continues: "Most of the world's reactors have large diesel backup systems for emergency power, even if the reactors have been turned off, permanent cooling must be maintained over the reactor cores to avoid meltdowns. Diesels are not ideal backup systems for Y2K problems. Many have embeedded computer chips that may fail during the clickover. Paul Gunter, director of the NIRS Reactor Watchdog Project, reported to the NRC that existing backup systems "frequently don't work and are subject to multitudes of problems." Gunter warned, "This is just the tip of the iceberg, our investigation of these generators is continuing and we are finding they are even less reliable than we had believed."

another quote in the article: "Gunter warned, "This is just the tip of the iceberg, our investigation of these generators is continuing and we are finding they are even less reliable than we had believed".

another statement: "When pressed on the issue the NRC admitted, "In a worst case scenario...a plant trip could result in a loss of off-site power and subsequent complications in tracking post-shut-down plant status and recovery due to loss of emergency data collection and communications."

The entire article is posted at http://www.thenation.com/issue/990315/0315sanders.shtml

I don't know anything about these commentators, but with issues like these will they be able to leave the plants on line? Or are these not very critical issues.

If these have been addressed in another "thread", I apologize for the long post.

-- Anonymous, March 02, 1999

FactFinder:

Thanks for this information. I even like the numbered list:

1. This is one of my personal favorites, partly because I can do it at work (since I am in the industry), and also because of the good information.
2. I am interested in your findings; I don't like "swipes" either. It has been hard for me to see where you were comming from at times. It seems to me that you and Dr. Frautshi agree to a large degree.
3. I actually think that many of us are trying to answer questions including Rick, and Bonnie. I am not sure if I properly understood your comment...
4. I was happy to see your position on this issue. It was a source of confusion to me.
5. Your assessment is encouraging.
6. This is the part that I really find interesting. I also agree. My experience as a software developer causes me to agree with this as well. I have also found that failures at the device level haven't been catastrophic. As a workflow developer, I know that a little failure at the source, can become a huge failure in the end. That's why I believe that process complience is much more interesting than component compliance. This is where I think you have a "leap of faith." Perhaps you are thinking that, since the component failure isn't catastrophic, then the process should work as a whole. This is where my experience would lead me to disagree, if, indeed, that is what you are thinking. Remember that when the "paging" satellite went out, people couldn't buy gas. How does this make sense? Was the oil industry "misusing" the signals from the satellite?
7. I would be very interested in a paper.
8. Could you provide a link to this?
9. Although I think that the bugs will cause minor problems for the PC owner, I think that many won't like their PC and will want to get a new one when the show up. It might cause some to distrust everything on the computer, don't you think?
10. I like the two witness rule. Almost anyone can write an article.

-- Anonymous, March 02, 1999

I found the paragraph numbering that FactFinder used and the following of this number system by Reporter to be very helpful. It would be great this were used more. This would be a great enhancement to a great forum.

The quality of the data coming in is higher and the thoroughness of the posting is better resulting in an emerging picture of what is happening in the utility industry.

I also feel that the level of opinion and emotion is decreasing on this forum and that also leads to enhancing our prognosis.

Rick, your original objectives are really being met.

-- Anonymous, March 02, 1999

1. Right.

2. Dr. F.'s paper is pretty good (FF isn't seeing the big picture -- there I feel better ;)

3. CL is participating in an open discussion, just like the rest of us.

4. I've ordered a deluxe year's supply for four adults, it gives me peace-of-mind. It'll feed a group of 16 family and friends for 3 months (till the spring, when we can plant :-) If I don't need it I can donate it to charity and get a tax write-off.

5. Good. And how many plants might that be? Are you over-seeing the whole operation or focused in a specific functional area? Are you 100% convinced there won't be any problems in the programs you have been involved in? Maybe you will be able to power up your PC but you might not be able to get on the 'net and say "see?". To get on the net your local telephone switch will have to work, plus all the switches in-between, plus all the Cisco hubs, plus your ISPs server, plus... And come Jan 31st maybe you won't be able to power up your PC whenever you want because power in your area is being rationed due to oil and coal shortages.

6. Have you actually done any fully integrated end-to-end system tests to see the effect of cascading errors?

7. I agree that the bugs are minor on a case by case basis. My major concern is the effect of millions of cascading world-wide glitches all happening within hours of each other. Very few people understand systems analysis well enough to even begin to comprehend this in any rational way, and nobody knows how it's all going to pan out ten months from now. Y2K is going to be the biggest Common Mode Failure in recorded human history. That's a fact. You can quote me on it (the previous global CMF was approximately 12,000 years ago but it took all the known records with it :-) :-).

8. At first you seem to be downplaying problems with PLCs and then you say, "I would also suggest looking closely at the custom written application program for any PLC's with real time clocks, to see if the program uses dates in a way that could cause a problem due to any operating system bugs identified by the manufacturer or in testing." Argh! This helps illustrate one of my biggest concerns and that is the highly integrated nature of modern equipment. A high-end modern PLC is made up of an industrial PC (IBM/Wintel compatible), a BIOS, some proprietary control logic, solid-state relays and A/DACs, an operating system, and a mix of off-the-shelf and custom ladder-logic application code. The BIOS manufacturer says "we're Y2K compliant", the OS vendor says, "we're Y2K compliant", the PC RTC is Y2K compliant, the PLC vendor says "apply this patch to the PLC firmware and upgrade the Windows NT client program to version 5.2 and you'll be Y2K compliant." Hunky-dory right? Wrong. Because one line of code in the custom application is broken but was never end-to-end tested. Fall-down-go-boom.

9. Please don't say things like that. I don't think you have enough information to say that the PC RTC problem is overblown. Maybe in the power industry it is. I don't have enough information to say otherwise I just highly doubt it. Yes, in most cases the RTC can be set manually after the fact -- but that is a fix-on-failure procedure and may not be that wise for a PC controlled intensive-care-unit, or a PC controlled air-traffic-control computer, or a PC controlled railroad switch room, or a PC controlled traffic light system, or a PC controlled water-filtration plant, or a PC controlled downlink for the Space Shuttle, or a PC controlled nuclear power plant for that matter. There are at least 500 million desktop PCs out there and at least that many PC based embedded systems. Also, the PC lockup problem is not a myth, I've seen it with me own two eyes. It all depends on the application; from the clock chip up through the BIOS, the operating system, the middle-ware to the application and out onto the net through an SNMP agent. If any piece of code along the way decides that the date is funky it can take a code path that has never been executed before and maybe never tested before. Fall-down-go-boom.

10. I don't rely on human sources, I rely on computer sources. The computer sources don't lie and they tell me there are going to be problems. Much has been fixed and it sounds like everything's is going great with your program. But I personally think that we're not even a third of the way there from the global, cross-industry point of view.

Regards, --AJ

-- Anonymous, March 02, 1999

Drew - Your post was a great read and one of the reasons I like to visit this forum - I often leave having accidentally learned (or re-learned) a little something. The android story is a real gem, as is your coffee cup example. More than just applicable to the Great Y2K Debate and reporting principles, this speaks to the human nature in general. I am going to keep this one for future reference, not for myself of course, but, ahem, for others that don't always view the big picture.

And your speech lead "I'm not a Y2K expert, but I play one on TV." is hilarious.

I agree with your observation about different opinions on Y2k even within the industry, but I do see a general consensus forming in several key areas.

Finally, you expressed in your post admiration for Rick Cowles humility, and I couldn't agree more, this is one of the things that impresses me about him as well (I also thought the same thing about Roleigh Martin in a post he made here expressing his limitation of knowledge in one minor area of discussion- guts, humility). I do take exception, however, to your implying that I am somehow lacking in this virtue. Just because I haven't expressed it doesn't mean I don't have it....as a matter of fact, I have lots of humility, way more than most here, and......dammit Jim ....[Warning - previous sentence was intended as intellectual humor ending with a totally unrelated Dr. McCoy to Kirk dialog from Star Trek. For benefit of the humor genes of most male readers, this sentence was equivalent to Curly of the three stooges poking Larry in the eye, accompanied by a "whoop, whoop, whoop!"]

-------- Steve - Your Statement and Question: "It is clear that the number of problems being found with embedded systems is less that originally anticipated. Why then do we have so many utilities that won't be through with their remediation and testing until this summer or fall? Are they working on low priority fixes, like the ones you describe, instead doing important testing?"

Steve, let me first humbly caution you that the following is just one person's opinion. Now, having said that, here are the Total, Undeniable, Unquestionable Facts: Some Y2k upgrades can be done relatively fast, but others that involve plant modifications and must go through the design and implementation process and procedures. In nuclear, it typically takes many months to go from identifying a problem until the fix is designed, installed, and tested (this can be expedited for critical problems). Some modification work must be done offline and would be scheduled for a routine plant outage. Vendor equipment and service availability may also be an issue (this has caused some minor delays for me). Without knowing the circumstances of all these other utilities, additional factors might be project management oversight, process efficiency, and scheduled outage dates. This may not be everyone's story, but this is mine, just one story in the naked city....;) -------

Reporter, 2. I haven't found an embedded system paper by anyone that is reality based, i.e., based on the types and severity of y2k bugs we are actually finding. Most have educated speculations of the types of problems that might occur, but that have not been found or are highly exaggerated. These papers are myth makers, not myth breakers. The authors can change this at any time, if they decide to incorporate findings that have been wrapped up with the assessment phase - the y2k enemy in embedded systems is known, and its totally unlike whats described in the current papers. In my humble opinion (added for Drew...lol).

3. You are so very right, I did not mean to imply that you and the rest weren't as helpful as CL. I truly find all of you very quick to answer questions, etc.

6. I appreciate your feedback from a software developers perspective. As far as component vs. process issue, I don't assume anything, either I or the vendor tests...maybe I am the one misunderstanding what you are saying here.

8. Previous Allen Bradley Post

9. Sounds like a good reason to buy a new PC to me...but will the wife go for it??;)

Thanks for the feedback Reporter, it really helps. ---------

Linda,

The information you are getting from your co-op appears to be Y2K legal filtering, and thats unfortunate when real information is needed.

And believe it or not, the NIRS "Reactor Watchdog Project" has somewhat of a point, in that EDGs haven't been the most reliable things in the industry....but the "many have embedded chips that may fail during the rollover" is mere speculation. You can count on this - when a Y2k bug that could render an EDG inoperable is found, you have your safety system "smoking gun" y2k bug....expect an NRC part 21 or some type of notification ..and to the best of my knowledge, this hasn't happened...

------- AJ, Thanks for the feedback, will respond, but need a break first. :)

Regards, FactFinder the Humble

-- Anonymous, March 02, 1999

Most Humble Fact Finder,

Oh, I didn't mean to imply at all that you weren't humble. In fact, you should take pride in your boast of humility :) No, seriously, that never even entered my mind; I just meant to point out this virtue, IMHO, of Rick's (and I agree about his guts, too- at least he says publicly what a lot of people think privately).

I realized last night that I didn't make myself clear on the two source thing (I realized this after I posted it, of course). Basically, I only meant that some things don't need double-sourcing, whereas others need more than two, and that "two sources" is not always a usable rule of thumb. I had a literal plethora of sources before I started even discussing the seriousness of Y2K with others.

Must run; pressed for time as usual.

-- Anonymous, March 02, 1999

AJ, Technology, gotta love it! I don't have time to discuss all of the issue, but do want to hit the highlights.

[FF's original post] 8. I have already done a post in this forum somewhere on Allen Bradley PLCs, complete with links to the minor y2k bugs that a few of them have but which will not prevent the PLCs from operating and should not cause any problems. I would also suggest looking closely at the custom written application program for any PLC's with real time clocks, to see if the program uses dates in a way that could cause a problem due to any operating system bugs identified by the manufacturer or in testing.

[AJ's reply ] 8. At first you seem to be downplaying problems with PLCs and then you say, "I would also suggest looking closely at the custom written application program for any PLC's with real time clocks, to see if the program uses dates in a way that could cause a problem due to any operating system bugs identified by the manufacturer or in testing." Argh! This helps illustrate one of my biggest concerns and that is the highly integrated nature of modern equipment. A high-end modern PLC is made up of an industrial PC (IBM/Wintel compatible), a BIOS, some proprietary control logic, solid-state relays and A/DACs, an operating system, and a mix of off-the-shelf and custom ladder-logic application code. The BIOS manufacturer says "we're Y2K compliant", the OS vendor says, "we're Y2K compliant", the PC RTC is Y2K compliant, the PLC vendor says "apply this patch to the PLC firmware and upgrade the Windows NT client program to version 5.2 and you'll be Y2K compliant." Hunky-dory right? Wrong. Because one line of code in the custom application is broken but was never end-to-end tested. Fall-down-go-boom.

**** My response**** I like testing as well, AJ, no disagreement here. The testing in the industry of highly integrated systems such as DCS and PLCs have not found serious problems to date from the information I have access to (unless you count data historian problems or incorrect date displays as serious). I have read about shutdowns of systems in other industries, but haven't seen it here yet. My experience has been that most PLC applications do not use dates in the PLC itself, but of course some do - that doesn't mean the PLC will crash, and in fact, it very likely will hum along....the "Fall down go boom" scenario is something that is much less common than the minor problems. Why do I suggest looking at the PLC applications for date usage? The PLCs I have researched have no y2k bugs that in themselves would cause the PLC to crash, i.e., will not fall down go boom, however the application program COULD cause a problem with a y2k bug, the seriousness would depend on how the date was used. Testing is great, but it doesn't take long to look at the ladder logic or other documentation to see if and how dates are used, you can save a lot of time before going out to test. Most PLC applications that I have been involved with don't have real time clocks, not needed for most process controls. This is my experience, you may have a Detroit auto plant shutdown case on your hands, but these complicated systems aren't nearly so fragile IMHO...most date bugs get passed and passed...and do nothing at all signficant :) And we won't have to worry at all about the standard solid state relays used in the utility industry, they don't use RTCs or dates in any way...

[FF's original post] 9. PC hardware Y2K bugs are way overblown as well. Yes, most PC's made prior to 1997 are not compliant, and a lot made in 1998 are not compliant and will not automatically rollover on the real time clock while they are shutdown. However, the untold story is the vast majority of these can be manually set for January 1, 2000 and from then on will hold the correct date. For home PCs I don't even recommend flashing the BIOS to make the rollover work - why risk a bad BIOS upgrade problem when you can manually set the date? (By the way, even the ones that cannot be manually set will continue to run, just with the wrong date - the crashing PCs was just another one of those wonderful Y2K myths). Windows 3.1, Win 95, and NT4.0 are all basically Y2k ready, the dates will work properly. There are a few minor issues such as the filemanager in Win 3.1 (the only problem here is that the file date will be foobar ";0" or ":0" (I can't remember which) for the year 2000 instead of "00" (I believe windows explorer in Win95 has the same problem, but please verify) - you can fix these with patches from the Microsoft web site. I have done this and it works fine. The y2k bugs in PCs that are of major concern are in the applications that use dates in important ways .

[AJ's reply] 9. Please don't say things like that. I don't think you have enough information to say that the PC RTC problem is overblown. Maybe in the power industry it is. I don't have enough information to say otherwise I just highly doubt it. Yes, in most cases the RTC can be set manually after the fact -- but that is a fix-on-failure procedure and may not be that wise for a PC controlled intensive-care-unit, or a PC controlled air-traffic-control computer, or a PC controlled railroad switch room, or a PC controlled traffic light system, or a PC controlled water-filtration plant, or a PC controlled downlink for the Space Shuttle, or a PC controlled nuclear power plant for that matter. There are at least 500 million desktop PCs out there and at least that many PC based embedded systems. Also, the PC lockup problem is not a myth, I've seen it with me own two eyes. It all depends on the application; from the clock chip up through the BIOS, the operating system, the middle-ware to the application and out onto the net through an SNMP agent. If any piece of code along the way decides that the date is funky it can take a code path that has never been executed before and maybe never tested before. Fall-down-go-boo

**** My response**** Please re-read my post, the crashing PC myth was in the discussion about the RTC/BIOS rollover. It is a widely spread that the non-Y2k compliant RTC/BIOS can cause a PC to crash- this is a myth and I stand by it. But I am sure if we look long enough we can find a homebuilt by a guy named Fred....that falls down and goes boom. Thats not a standard IBM compatible PC and I wont count it ;) Yes applications can cause a crash., I have Microsoft products, so I know this is a true statement...lol. Thats exactly why I ended by saying the y2k bugs in PCs that are of major concern are in applications that use dates in important ways. And I have seen an application crash due to a y2k bug - 1 in several hundred, however...a fairly rare puppy...I am curious as to what ratio of minor app problems to major app problems you have seen.

Finally, I clearly stated "For home PCs..." to just enter the date on Jan1. 2000 for non-compliant PCs that will accept the date manually. (This is a fix for ANY PC that is shutdown every night as well :) For PCs that must be left running, including MMIs, then of course you should fix in advance - even though there is a very very strong possiblity that its still not an issue if your running NT, Win3.1, Win95, because almost all applications get their date/times from the operating system, NOT the RTC CMOS - so it very likely would even be an issue until you shutdown and reboot anyway! (Since on reboot the operating system grabs the RTC date/time).

Regards,

-- Anonymous, March 04, 1999