For a good Y2K read, check out:
http://language.perl.com/news/y2k.html
>
>
> HI All;
>
> I got this email below from another list. I'm not a hardware person, so
> I'll ask you guys. Is this true, that there are date functions imbeded in
> chips? Ones that can blow up on Y2K? To be honest, this letter comes
> across as propaganda to scare people that are not too computer ilterate.
> If this is wrong, what is right?
>
>
>
> ____________________________________________________________________
>
> Dear friends,
>
> I have been contributing to this list since about last September. I have
> enjoyed much and learned much. I hope also that I have been able to help
> others. I am in a unique situation to offer some perspective on the year
> 2000
> computer problem. A little history first.
>
> I entered the workforce after graduate school in 1972. I worked for
> several years for a large national computer manufacturer. I wrote software
> for banks and business. I wrote savings and checking programs. I wrote accounts
> payable, accounts receivable, and payroll programs. I am afraid that I am partly
> to blame for the fix we are in now. In the late 70's and early 80's I worked for
> a large custom silicon chip manufacturer. I was not directly involved with the
> "programming" of the chip, but I worked VERY closely with those that were. I
> saw the same date schemes used in the custom chips as I used in the bank
> and business programs. At that time "real estate" on a chip was very
> valuable.
>
> Every thing possible was done to conserve this costly silicon. The
> development of a custom chip could cost anywhere from hundreds of thousands to
> millions of dollars. I have seen many date dependencies programmed into chips,
> All using 2 digit year representation.
>
> I write the above so that, number one, you understand why I am
> preparing. It is not because I read about the problem somewhere, it is because
> I lived through the creation of the problem. The second reason I mention is to
> also share a perspective that I have. The Y2K computer problem has been
> referred to as a computer bug. It is not a bug. A bug in a computer program is a
> piece of code that reacts in an unpredictable manner.
>
> A bug can usually be isolated in a timely fashion, and depending on the
> severity, is usually corrected quickly. A bug affects only a small part
> of the functionality on a program.
>
> They Y2K computer problem is not a bug, but rather a designed part of
> older computer systems. Therein lies the problem. A design flaw that permeates
> the entire system, as does this, is not fixed quickly. This is not a
> relatively simple maintenance problem, but a redesign problem. The original
> design documents are for the most part incomplete or missing. The best solution
> would be to replace the systems, but there is not enough time. The second best
> solution would be to redesign the date routines and rewrite enough of
> the system to make it work but there is insufficient documentation and a
> lack of understanding of how the legacy systems work. The solution that
> has been chosen, in my opinion is the least likely to succeed. That is to treat
> it as a bug. Make it a maintenance problem.
>
> This all sounds rather hopeless, but I have not lost hope. When the
> going gets tough the geeks get tougher. I still hold out hope for success. BUT
> I will continue to prepare for the worst.
>
> I have been part of the y2k team for the computer systems I support at
> work. We have had success in remediating the few problems we have uncovered,
> and we have uncovered several. The systems I support were newly installed and
> programmed within the last 10 years. We expected to find no problems,
> but there were some. There is success out there, so continue to hope, but
> don't stop your preparations.
>
> I hope that in sharing the insight that I have from the unique situation
> that I am in will help some of you and hurt none. I mostly hope it will help
> anyone that decides there won't be a problem because their PC works OK. It is
> not about PC's.
>
> Dick
>
>
>
