I've spent most of the last year working on making various computer systems Y2K compliant. Most of the focus that we humans have had is on large systems: big data bases; mainframe and mini computer programs written in legacy (old) languages (like RPG and COBOL); and networked financial systems.
In most cases, we've overlooked the small stuff: e-mail clients; office automation (word processing, spreadsheets, etc.); general PC systems' programs. These have not gotten a lot of attention, because most people think that personal computers are naturally compliant and not a serious issue. It is a mistake to make this assumption.
These overlooked problems are more about poor planning and leadership in Information Technology areas. Everywhere, in government and the private sector, it's about management by individuals and groups who know nothing about the mechanics of the issues at hand; consultants who can't and solutions that are not.
Jan. 1 of 2000 is not an Event Horizon for Y2K issues.
It is a cumulative effect. The idea that most people have about New Year's Day being the deadline for failure is totally ludicrous. In my honest opinion, April 1 of 2000 will be more of a telling day than any other. On this day, financial experts will be looking at the quarterly financial information from the first quarter of the year. This is when non-compliancy will raise its ugly head. However, while accountants looking at financial data may see trouble at this time, the rest of us may never see our problems, because we don't know what we're looking for. We'll just go along, merrily overlooking some really bad data.
Y2K issues in office automation and financial computer systems are about the interaction of data between dissimilar software systems. Essential about the import and export of data.
Here's an example: If I export a spreadsheet file from my PC to a database on your system, and it truncates the date, you end up with garbage data. Actually the data all looks good, but at the end of a specified time period, you can't correlate it. It makes no sense.
I recently spent several months working for a large and well-known Boulder company which had me and one other concentrating on a legacy database. While most of what we were doing had little to do with Y2K, we were asked to look into it towards the end of the project. While the software system in question is compliant, the client computers and network servers that were editing that database were not. And still are not, I believe. We continued to report this non-compliance information to the system's administrators, but were mostly ignored, because it wasn't budgeted for, or in the original plan to work on.
This will come out in the wash, when the individual computers have a negative effect on the overall system.
Personal computers are not inherently Y2K compliant. Apple doesn't make a product that is any less problematic than any other personal computer. This is about software, not hardware. If you have bad data on your system due to a problem with the date and you give that data to someone else, you will transfer the problem to them. Almost like a virus.
Everyday I hear people tell me that they have nothing to worry about because their office uses Macs, Macs, or
The complacency really comes into play when folks who haven't done anything to become Y2K compliant experience the passing of the New Year without incident. After which they are sure that they're going to be okay, and ignore the possibilities that they are really in trouble.
Paul Tiger is the Emergency Services Developer for the Boulder Community Network.
He can be reached via e-mail at ptiger@leu-rescue.org.
The above letter was printed in the Daily Planet on January 5, 2000.