ROTTERDAM REPORT REVEALS LESS THAN ROSY OUTLOOK FOR PC'S AND DESKTOPSgreenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread
As a Y2k consultant and member of a Y2k Think-Tank, I've been predicting major 'short date' problems for PC's and desktops after the rollover. I hoped I was wrong.
A report and presentation made to the Royal Society in England on Oct. 5, 1999 highlighted the same concerns. See this TB2000 thread to see a copy of that report: http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=001qFx
For 3 months, a company called Year 2000 Consultants BV in Rotterdam, has been testing these predictions by running independent tests.
A "First Public Summary" is available from their web site at: http://www.y2000c.com/rotrep.html (web site is under construction)
The Public Summary is free, but Adobe Acrobat is required for downloading or viewing.
The first "automated" test results show a 50% to 150% increase in errors. They advise that ALL systems will be affected.
A second set of "simulated" test results are scheduled to be released in mid-December. The report strongly hints that the upcoming "simulated" results will be worse, and they will more accurately reflect "real world" usage.
If these guys are right, many small and mid-size businesses depending on PC's and desktops could be in BIG TROUBLE.
The President's Council on Y2k was informed of preliminary Rotterdam test results and short date issues a couple of month's ago. Since we haven't heard anything from them, I can only assume that it's a non-issue.
Do PC's or desktops ever tie into "Mission Critical" systems?
-- Brian Bretzke (firstname.lastname@example.org), November 30, 1999
You bet they do-unfortunately. Many host computers are mainframes.Even if they didn't it could be reasonably interpreted that, if the boys in Rotterdam are right, the failure of PC's is certainly enough to bring the roof down on our collective head.
-- Get Real (email@example.com), November 30, 1999.
---sell pc clone now, get mac. sell Macro$cam/Intel stock, maybe buy Apple/Motorola. That is, if you only think it will be a 2-3 on the doomer scale. Me, I buy "commodities"...hehehehehehehehehe
evaporating electrons zog
-- zog (firstname.lastname@example.org), November 30, 1999.
Thanks, Brian. Will read over lunch.
-- Lewis (email@example.com), November 30, 1999.
Well, I've had a couple of quick reads, and it's different than I expected. I encourage folks to download it and read it themselves.
Their main finding seems to be that the presence of short date formatted routines in compiled files will cause a significant increase in the number of PC crashes and freezes during 2000/2001. IOW, get used to the blue screen of death. I didn't read any reference to the idea that unremediated systems "accumulate" errors over time, ultimately seizing up. That idea was in the White Paper, but not in this report. Correct me if I missed it.
Now for an indiidual PC, this is annoying but probably not a disaster. Sort of like having your PC magically transformed into a first generation pentium Packit Back running a Win95 beta. In the rain.
But imagine a place with 100 PCs. or 1000. Or 10,000. Clearly a simultaneous performance degradation would have serious impact on productivity. Not to mention having to replace all those PC's thrown out of windows by frustrated users...
In short: You don't want to be working a Help Desk next year.
These results came from a test using an industry standard, scripted routine test program. No multitasking. The next report will include the results of testing the same sytems with more realistic workloads. They expect worse results, although they don't explain why. Probably because the more apps you use, the more .dlls you call, the more errors occur.
The test environments were two matched sets of 2 PCs and 1 server. One set of PCs were repaired with the MFX2000 product. Those had a very small increase in errors. (note: I'm broadly summarizing the rather complex results here. Contrary analyses welcomed.)
One odd omission was that there was no mention of server performance. PC's crashing 50-150% more than normal is one thing. If servers start doing that, or machines controlling automated production lines, we got trouble in River City.
To the top for more comments. If none, I'll start a new thread. IMHO, this is an important issue to understand.
BTW, was the flap over the Crouch-Echlin time dilation problem big news when the Presidents Council heard about this? It's pretty arcane stuff, and frankly I'm not surprised if they didn't understand it, or felt it was another unprovable phenomenon.
But they better understand it now.
I can see this being a huge litigation issue next year. Is it a warranty issue? Whose compliled files are causing the problem? Who pays for new software? Could get ugly...
-- Lewis (firstname.lastname@example.org), December 01, 1999.
Brian is inventing a problem and selling the solution. It's a crock of shit.
No? Post some sample source code that demonstrates this. I'll build and test it, and I'll humbly apologise if I'm wrong.
-- Colin MacDonald (email@example.com), December 02, 1999.
Please don't blame me for creating the Y2k problem. I've spent a lot of time and money on personal preps for my family, as I'm sure you have.
Many sincere and honest people have been working very hard to develop and identify solutions for Y2k problems for mainframes, embedded systems and personal computers. No one has found the SILVER BULLET.
For some reason, you seem to have categorized me as a "snake oil salesman" in your flames regarding object code technology.
Download the Free audit tool from http://www.tir.com/~bretzke/free.html and run it on your computer. If you find short dates, you can wait until after the first of the year and see if the creeping corruption problem starts to show up on your system. Then you can make a decision as to the validity of the Royal Society and Rotterdam reports.
It sounds like you have a strong technical background. If you are involved in embedded system remediation, I would highly recommend the Delta-T Probe. It's the best tool available to identify embedded system problems. Delta-T can't fix em, but is quickest way to do end- to-end testing as recommended by NIST.
Please don't blame me for creating the embedded system problem either!
-- Brian Bretzke (firstname.lastname@example.org), December 02, 1999.