Some of my friends are telling me that they have reset there older computers clock and they are working fine. They therefore reason that Y2K could not be that big a deal. I use computers everyday, spreadsheets, word processors and data bases. Yet I dont really understand the "magic" behind the screen.

Therefore, I really dont know how to respond to them. I tell them that hardware and software are two differant issues.

Can someone explan to me (us) how an older (say 386) computer can boot up and work fine when the clock is set forward. An answer will go a long way in my quest to educate my area of the world. Thanks ww

-- WAYNE WITCHER (WWITCHER@MVTEL.NET), November 25, 1998

Answers

You and your friends are missing the problem. True, some (by no means all) PCs are broken at the hardware level; various effects like the clock skipping a year, jumping back to 1980, or (most insidious) becoming unreliable after 2000 (eratically losing, or sometimes gaining, time)

All of this is but a small facet of the problem. The BIG PROBLEM is with the PROGRAMS that run on the computers, and the DATA that they process. If the data represents 1999 as 99, and 2000 as 00, the first time the program has to process an 00 it's doing something that it may never have done before.

A very good programmer will have written in code to handle this event and tested it. Such a program is Y2K-ready even though it uses two- digit dates (another common misapprehension is that seeing YY means automatically that it's broken).

Unfortunately very good programmers are rare. A less good one will have put in the code, but not tested it. Somewhere between 1% and 90% of untested code is wrong (depending on how less good the programmer is)

A not very good programmer, or one in it only for the money, or one forced to stick to a specification dreamed up by pointy-haired managers, or one assuming in 1970 that nothing he wrote then could possibly still be in use by 2000, won't have anything in there to handle the 99-00 transition at all.

And on top of all this, those who suggested to their managers that Y2K remediation ought to have started in 1985 or 1990 were (AFAIK) universally derided. "We'll fix that nearer the time" was the standard pointy-haired manager comment. The same manager was wedded to the idea of "downsizing" which typically meant that as soon as a system was working, you fired everyone who understooh how its innards worked. Now those same managers are discovering that they have to accomplish ten years' maintenance work in 11 months. On dear.

And on top of all this, there's the problem of data-pollution. Systems have been connected together so that one passes its output directly to another, and often the data-validation that gets done is deficient. So, even a program that is 100% OK by itself with respect to the 99-00 transition may be led astray by being fed scrambled data originating in another organisation that hasn't fixed its problems.

And on top of all this, there are feedback problems. What good does it do a telemarketing outfit to have all its systems OK, if the phone company stopes providing service? If the electricity goes off, very few computers will be working, with fixed programs or otherwise.

I hope this helps. Please don't have too many nightmares. It may well be like the aftermath of a war, but despite everything I still feel that the doom-mongers are underestimating human resourcefullness when the chips are down. But it sure as hell ain't just a little problem with the hardware in that box you call a PC that you fix by buying a new one.

-- Nigel Arnot (nra@maxwell.ph.kcl.ac.uk), November 26, 1998.

Nigel and others:

Thanks your time and effort responding to my questions. I have a non-tech understanding of the issue but do not have the deep understanding some of the programmers do on this forum.

I think that it is commendable that you guys take the time to respond (over and over again).

I plan on printing this thread out and handing it out to my friends (so keep the information coming)so if you would like, please indicate your qualifications.

I direct others to this web due to your debth and breath of knowledge and your qualifications will hopefully convert the naysayers.

thanks again. ww

-- WAYNE WITCHER (WWITCHER@MVTEL.NET), November 26, 1998.

Wayne,

Don't know much about this stuff either, but here's a recent article I read. It would seem that the newer Pentiums are fairly safe, but anything else might have perhaps a 50/50? chance of survival? Good luck.

-- infoman (infoman@web.com), November 26, 1998.

Wayne,

Oops! Here's that link:

http://www.cnn.com/TECH/computing/9811/25/oldpcs.y2k.idg/

-- infoman (infoman@web.com), November 26, 1998.

# # # 19981123

FWIW: Brand-new top-of-the-line computers from Compaq, Hewlett- Packard, Micron, and Gateway failed CMOS/RTC tests.

What would _you make of this, Wayne? How the heck could this happen? ... Are we in trouble, or what?!

DON'T TRUST ANYONE RE Y2K READINESS! THAT'S THE TRUTH! ( DON'T EVEN TRUST ME! ) TRUST, BUT VERIFY EVERYTHING!!

Regards, Bob Mangus

mailto:rmangus@mail.netquest.com

FEDERAL COMPUTER WEEK

---------------------------------------------------------------------- ---------- NOVEMBER 16, 1998 ---------------------------------------------------------------------- ---------- Y2K compliance tests

BY ANDREAS UITERWIJK (andreas@fcw.com)

If you're buying new PCs this fall or winter, you need to make sure they'll work in the new millennium. That's why we conducted Year 2000 compliance tests on the 450 MHz Pentium II PCs in this comparison.

The issue of PC Year 2000 compliance is a sticky one for federal buyers, and little guidance is available from policy-making bodies. The President's Council on Year 2000 Conversion offers generic Year 2000 contracting language that doesn't specify whether a PC needs to have a compliant BIOS or Complementary Metal-Oxide Semiconductor/Real Time Clock (CMOS/RTC). All the language says is that the PC must "accurately process date/time data...from, into and between the twentieth and twenty-first centuries and the years 1999 and 2000 and leap year calculations.''

We found that all six systems tested featured the most common Year 2000 fix for PCs, which involves updating the system BIOS. However, only two systems had a compliant RTC in the CMOS chip. The systems from Intergraph Federal Systems and SMAC Data Systems Inc. passed all five tests. The systems from Compaq Computer Corp., Micron Electronics Inc., Hewlett-Packard Co. and Gateway Inc. failed the CMOS/RTC test.

CMOS is a type of chip in a PC that is connected to the battery and runs the RTC, which gives time and date information to the BIOS. The BIOS is a set of routines stored on a chip that handles all input and output functions. Most motherboard CMOS chips are based on a 1984 IBM Corp. AT specification, which allowed for a 99-year calendar clock. This two-digit calendar is the culprit causing PCs to fail more demanding Year 2000 compliance tests. When the CMOS/RTC reaches Year 99, it rolls over to 00. This makes the computer believe it's 1900 and not 2000.

However, in most newer PCs the BIOS has been programmed to automatically convert a 1900 date to a 2000 date where appropriate. Because most software programs make calls to the system BIOS to get time and date information, this fix will solve the Year 2000 problem for most users. However, some vertical and even a few consumer applications get their time and date information directly from the computer's CMOS/RTC. These programs will fail unless the CMOS/RTC has been updated for Year 2000 compliance.

To test Year 2000 compliance, we used a diagnostic software program called Fix 2000 from a United Kingdom company called eurosoft. Fix 2000 consists of two parts: a suite of tests that checks a system for Year 2000 compliance and a software fix that can be applied if a system doesn't pass the tests. A hardware fix also is available from the company.

The suite of tests first sets the CMOS/RTC date of the system after Jan. 1, 2000, and then reboots the computer to see if the date is properly held in the system's CMOS/RTC. The next test determines if the system clock is functioning properly after the date change. The third test checks the status of the battery, and the fourth test checks whether the system will keep proper dates during leap years. The last test -- and the one that many systems made by U.S. computer companies will fail -- is the CMOS/RTC clock test.

Should this matter to government PC buyers? Not if your applications make calls to the computer BIOS for time and date information. However, if you're running applications that make time and date calls to the CMOS/RTC, you need a system with a four-digit CMOS/RTC. Your software vendors or your internal programmers ought to be able to tell you whether CMOS/RTC compliance is an issue for you.

If it is, and your computer doesn't pass this test, you have two options. You can use the Fix 2000 software to install a program that will catch any date or time calls to the CMOS/RTC and correct the date. However, this fix works only with DOS-based operating systems such as DOSxx, Windows 3.11, Windows 95 or Windows 98. An option for Windows NT users is to place an ISA card, also from eurosoft, into the system to intercept all date and time calls made to the CMOS/RTC and return the proper date to the programs. We found the software and card solutions successful and easy to implement. The downside to the software solution is that it lasts for only three years. The Fix 2000 software and board can be purchased from Pulsar Data Systems at $30 for the software version and $85 for the board. Pulsar can be reached at (800) 775-7374 or www.pulsardata.com.

Buyers concerned about Year 2000 compliance should give extra consideration to the systems that passed the more stringent CMOS/RTC tests. Also, be sure to ask PC vendors whether they support a four- digit clock in the CMOS/RTC, rather than a two-digit clock, before you buy. ---------------------------------------------------------------------- ---------- # # #

-- Robert Mangus (rmangus@mail.netquest.com), November 27, 1998.

Hi Wayne,

"You use computers every day: spreadsheets, wordprocessors, and databases..."

Let's start from that beginning - I'll give you an example that might help. Remember - not everything will break. And not every failure is critical. And not every program will even notice. Most will be okay, or at least work "good enough" to be used.

But there are so many million other programs that will fail - catastrophically or completely - that the net damage we expect will be very harmful. But nobody kows how harmful. Remember that satellite failure last June? One program failed, it rotated one satellite the wrong direction one time, and 3/4 the pagers in the US failed until they could reprogram an alternate satellite. That's the kind of thing I expect to happen with Y2K - but not just once on just one program affecting just one satellite - millions and millions of times in millions of millions of computers aaffecting millions of systems worldwide.

Pretend your spreadsheet reviewed files from all your offices, and calculated daily, weekly, and monthly sales totals, then printed out what commission each salesmen would receive, and what to order, and what to ship. If the phones are down, or you have no power, or the phone switchboard in the other town was down, or the other town had no power, or the warehouse had no power, or the trucking company had no telephone system up, or the trucking compny computer had power, but couldn't schedule trucks because it thought "today" was a Sunday - you couldn't do your job, and you couldn't get paid.

If the spreadsheet program was receiving "negative" or 0.00 dates, what will happen? Some will print 0.00; some will crash th eprogram, some will not let enter new data, some will "skip" or "reset" the current line number - so the wrong custoemr gets the wrong inventory. Or the first customer in the list gets all the orders. Or the last customer gets all the bills, and the first customer gets all the inventory. Or the billing and receving is correct - but the printout parrt of the program lists 00/00/80 for delivery dates. Then crashes because there isn't that month.

There are weird and wonderful ways programs crash. If it reads the system date, and does something with that date, there is a strong possibility that the program will fail, or do something "weird and wonderful" with the data. Do you want to trust your monthly sales total to the random acts of violence commited by a crazed computer going "postal" on your paycheck?

-- Robert A. Cook, P.E. (Kennesaw, GA) (cook.r@csaatl.com), November 27, 1998.