Y2K One Last Time

S

Thread Starter

Steve Cliff

Hi Folks and Happy New Year/Decade/Century/Millennium:

This Forum certainly spent time discussing various aspects of Y2K and considering that the lights are still on, maybe some of our discussions were fruitful.

I am particularly interested in any "war stories" that you may have concerning things that went poof, and how they were fixed or worked around.
We all may learn from the various events and their fixes.

Yes, you can change the names to protect the lucky survivors.

As for me, I will contribute four that I saw in the new papers (any one with more details can jump right in) and one from home:

1) Three commercial nuclear power plant shut down shortly after mid-night, though the shut downs were not attributed to Y2K.

2) A Japanese nuclear plant lost its automatic radiation monitoring computer system, apparently due to Y2K problems.

3) The folks at NORAD had a real fretful time when, at midnight Moscow time, three missiles were launch from southern Russia. The Russian reps at NORAD did not expect this. Things were tense. The missiles were identified as SCUDs launched as a New Year's present to the Chechnya's by some local commanders.

4) A South Carolina City has a traffic light control system that works fine, is old, is not Y2K compliant at all, costs too much to make compliant, and cost more to replace. They set the date for the system to 1972 (the last
leap year that began on Saturday, like 2000) and all is well! If you folks remember, this was one of the suggested work around discussed on this Forum!

5) One of the three computers (PCs) at home had the clock chip that would stop at midnight and possibly not restart (according to testing done several weeks ago.) On Dec 30, I lied to the computer and set the date to Jan 3 and turned it off. Then, on Jan 2 I turned it on and set the date back to Jan 2. All seems well.

A nurse friend in the medical profession said that a bunch of Electrocardiogram machines failed in Britain. Any info anyone?

So jump in and share any war stories you have!

Cheers, Steve Cliff
 
B

Boudreaux, M (Mike)

I had a pretty bad run in with a Y2K glitch on my home computer on December 25. I was using my computer (Gateway Destination XTV) to download some files from the internet when everything started going haywire. Programs like GetRight, ICQ, Outlook Express, etc. would give me a general protection fault error when I tried loading them. I have had some minor problems with
my computer in the past because of all of the software that I had loaded on it - some dll version conflicts, driver conflicts, etc. Also, the performance was degrading because I had too much running on it, so I figured it was time to back everything up and reinstall Windows again - something I try to do annually.

I was hoping that reformatting my HD and reinstalling Windows 98 from scratch would fix any problems I was having, but half-way through the Windows setup program, I got another general protection fault error. I rebooted and retried the installation a couple of times before I decided that I was having more than just a software problem. I tore my computer apart, removing all of my peripheral cards (network card, modem, SCSI card, graphics card, etc.), and still experienced the same problem. I started to
wonder if something was wrong with my motherboard or my CPU.

I decided to get on another computer to search Gateway's support site and found nothing - but when I searched Microsoft's knowledge base, I found the answer to my problems (see Q187268 -
http://support.microsoft.com/support/kb/articles/q187/2/68.asp). Evidently, the problem was caused because my "computer's date (was) set incorrectly." I immediately went into my BIOS and sure enough, my date was set at 2099 instead of 1999. I changed the date back and everything's been running fine ever since.

Windows 98 may be Y2K compliant, but it's not Y2.1K compliant. I don't know what changed the date on my computer from 1999 to 2099, but it hasn't happened since and Gateway claims that none of their proprietary software would have done it. I was running the latest version of Network Associate's virus information, so I don't think it was a virus.

It makes you wonder if we're going to have Y2.03K, Y2.05K, Y2.075K, and so on... bugs in the future. My guess is that we're not finished with the Y2K glitch.

Happy New Year,

Mike Boudreaux
http://mike.boudreaux.net
 
C
Got one for you..

Nuclear density gauge on site "has developed a Y2K issue that was not apparent during the (vendors) testing phase".

Basically the gauge is reading full scale and until we upgrade the firmware there's not a lot we can do about it.

Bugger !!


Paul Clyne
CSR - Fibre Cement
[email protected]
 
M

Martin Cutajar

I can only comment on bug encounters at home.

1. On one PC, a few year's old, Gateway P5 - 100, everything was well when I checked just in from partying. The only problem : Powerchute Pro (UPS
mnitoring software) was performing a "Administrative Shutdown at 01/01/100".
I cancelled the shutdown and it seems all is well.

2. No problems on a home built PC.

3. On an old PC (a 486 DX2) date went back 1982, I reset the date and all seems well.

M. Cutajar
Malta.
 
L
Happy New Year,

Let's see... I use Lotus cc:mail and from time to time it requires a database reorganization. It recommended doing one which I did yesterday and the log which was generated indicated that the reorganization program was executed 1/4/100. I don't know if it is a
persistant bug, but it is not a problem. Also I heard of another cc:mail user in an HR department somewhere who didn't get the Y2K compliant version and created some problems when sending a message.

At home, we lost our Christmas card mailing list, but that was related to a cd-rom reader that my kids broke using it as a cupholder and my
wife's ensuing efforts to use her software which requires her to use cd's... of course that occured prior to the rollover and was not a result of the Y2K bug. It did delay any of our cards getting mailed until after Christmas, however, and some until after 1/1/00.

My homemade "Y2K Bugkiller Barleywine", which had been aging since last spring in anticipation of celebrating the rollover and surviving the aftermath, developed an unexpected and unwanted chill haze which hadn't been observed in the few bottles which had been opened earlier for testing. There wasn't even a computer involved except for my recipe/batch tracking software. ;)

Regards,

Lou Heavner - Austin, TX
 
R

Ranjan Acharya

<clip>
> Windows 98 may be Y2K compliant, but it's not Y2.1K compliant. It makes you wonder if we're going to have Y2.03K, Y2.05K, Y2.075K, and so
on... bugs in the future. My guess is that we're not finished with the Y2K glitch.<
</clip>

Refer to an article entitled something like "Bad Days for Software" from some time in 1999 in the IEEE Spectrum magazine for more details on upcoming date problems.

Many applications that are Y2K compliant run out of steam throughout the first fifty years of the next century (starting in 2001 ... sorry).

Of course there is the famous 32-bit Unix date rollover in 2^32 seconds minus 1 from 1970-01-01 00:00:00 GMT/UTC (2038-01-19 03:14:07 GMT/UTC or
something like that). Windows NT 4.X has an internal counter that runs out of steam soon too. It would be interesting to know what dates Windows 2000 is good up to.

Time to use star dates?

RJ

Ranjan Acharya 905-634-0844 x 238 (V)
Team Leader - Systems Group 905-634-9548 (F)
Grantek Control Systems http://www.grantek.com/
[email protected]
[email protected]
 
P

Paul McGuire

Y2K was probably the most glaring "date rollover" bug, but there are others that will continue to occur. Some are Y2K-like milestones, others are
recurrent (like the GPS date rollover that occurs every 1024 weeks, or ~20 years). I would not be surprised to learn that, now that we are past the
century's turn, we will be even more likely to see software shortcuts that represent the year to only 2 digits; that scheme is now good for nearly
*100* years, not the paltry 25-30 years that seemed like forever back in the 1970's. (One personal observation, as I formatted a logging timestamp as 00/01/04 this week - it is not immediately clear that this actually represents a date, or at least I'm not used to it yet. I changed the code to emit 2000/01/04, which is much more date-looking.)

One date rollover that I think will be especially interesting is when the Unix time() function that returns the number of seconds since Jan. 1, 1970
exceeds the size of the 32-bit returned integer, which is sometime in early 2038. I think this rollover is particularly subtle, and much more difficult to grasp than the straightforward (19)99 -> (20)00 problem. I think we are unlikely to see the same media hypestorm that Y2K generated (what would we call it? Y2^31K?). [BTW, time() is also implemented this way in MS's C++ on
NT, so it's not just a Unix problem.] For that matter, Y2K may even have lulled people into a level of complacency, given its failure to cause any sensational disasters.

I think when we say "one last time", it's really "one last time until the next time" (hmm, I think there's even a pun buried in there somewhere...).

Paul McGuire
ObjectSpace Fab Solutions
Austin, TX
pmcguire_at_objectspace_dot_com
- Advanced Process Control Solutions for the Semiconductor Industry -
 
R

Ranjan Acharya

More Y2K ranting.

A personal complaint of mine has always been the myriad of standards out there for writing dates. Especially confusing is MM/DD/YYYY (USA) or
DD/MM/YYYY (Elsewhere). Here in Canada it is especially confusing with people and companies using either the US or Elsewhere format and not quite making up their mind. I have seen web sites that cannot make up their minds from page-to-page either.

The IEEE has asked us all to take the time to switch to the ISO 8601 format i.e., YYYY-MM-DD (hh:mm:ss if necessary in 24-hour format) or long-format DD mmmmm YYYY. Much clearer!

RJ

Ranjan Acharya 905-634-0844 x 238 (V)
Team Leader - Systems Group 905-634-9548 (F)
Grantek Control Systems http://www.grantek.com/
[email protected]
Ranjan.Ach[email protected]
 
R

Ralph Mackiewicz

> One date rollover that I think will be especially interesting is when the Unix time() function that returns the number of seconds since Jan. 1, 1970 exceeds the size of the 32-bit returned integer, which is sometime in early 2038. I think this rollover is particularly subtle <...<clip>

"subtle" is an understatement. Insidious may be more accurate. What software is immune from this? Do the coders out there actually know what will happen to their programs when the number of seconds from January 1, 1970 goes negative (or to zero)? How can anyone actually "fix" this without changing all the O/S and applications? 38 years is
not that far away.

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
M

Michael Griffin

The only serious Y2K bug which I saw (fortunately it was not at work) was with a computer whose BIOS insisted on rolling over from 1999 directly to 2094, and wouldn't accept any dates in between. Various programs refused to function correctly (aborting after giving error messages) until the date was rolled back to before 2000. Since the same software worked OK
on other computers which had the correct date, I suspect the 2038 problem (or something similar) inside either Windows or the application programs (or both) being at the root of it. I haven't been adventurous enough yet to test this theory properly.
I suspect that this problem may be much more serious than Y2K. It is very widespread (not just UNIX), and a lot of equipment which was Y2K
compliant is not 2038 compliant. It is not unreasonable to expect many new machines today (or at least the software) to still be operating 40 years from now. If we have learned anything at all from Y2K, we should have learned how these sorts of date dependent bugs can catch up with us. Does anyone know what is being done about this?


**********************
Michael Griffin
London, Ont. Canada
[email protected]
 
R
If programmers are doing things correctly, i.e. using standard C library calls or derivatives, then it is enougth that the software is recompiled
with a 64-bit time_t definition.

This is already the case on some 64 bit systems, such as Linux on ALPHA/SUN/PPC platorms (and I suppose the merced).

This is of course a good point of OSS, software can be upfraded by re-compiling. Actually much OSS code has allready migrated/been upgraded
all over the place just by re-compiling.

Ralph Mackiewicz wrote:

> > One date rollover that I think will be especially interesting is when
> > the Unix time() function that returns the number of seconds since Jan.
> > 1, 1970 exceeds the size of the 32-bit returned integer, which is
> > sometime in early 2038. I think this rollover is particularly subtle,
> > and much more difficult to grasp than the straightforward (19)99 ->
> > (20)00 problem. I think we are unlikely to see the same media
> > hypestorm that Y2K generated (what would we call it? Y2^31K?).
>
> "subtle" is an understatement. Insidious may be more accurate. What
> software is immune from this? Do the coders out there actually know
> what will happen to their programs when the number of seconds from
> January 1, 1970 goes negative (or to zero)? How can anyone actually
> "fix" this without changing all the O/S and applications? 38 years is
> not that far away.
 
R

Ranjan Acharya

<clip>
> very widespread (not just UNIX), and a lot of equipment which was Y2K compliant is not 2038 compliant. It is not unreasonable to expect many new machines today (or at least the software) to still be operating 40 years from now. If we have learned anything at all from Y2K, we should have
learned how these sorts of date dependent bugs can catch up with us. Does anyone know what is being done about this?<
</clip>

It is not just the OS's it is also applications. We do some work with USData's FactoryLink. They use an internal counter (SECTIME) based on
1980-01-01 00:00:00 so they roll over in 2048. This means that many SCADA applications that survive until then may have problems too ...

Perhaps some 64-bit or 128-bit date counters / tools will stave off the day of reckoning (past the date when our sun becomes a red giant and swallows up the earth at least).

I agree with Michael -- this whole thing does not say much about the OS developers. After all 2038 really is not that far away from 1970.

The IEEE Spectrum article I mentioned a while back is "Bad days for software" by Capers Jones and was in the September 1998 edition. Here is an
interesting highlight:

Date Problem No. Systems

Year 2000 36 000 000
Y2KLeap 2 000 000

NATel. No.'s 25 000 000
Euro 10 000 000
US SIN 15 000 000
Unix 12 000 000
GPS 250 000

Jones notes that North America runs out of telephone numbers sometime before 2015 -- just imagine the problems for the guys in the IT departments as well as the costs of upgrading all the PBX's.

The US runs out of social security numbers (SIN) in 75 years (a long time), but Jones thinks that this will be more expensive to upgrade than Y2K --
better start now IT guys.

A good calendar URL is http://www.tondering.dk/claus/calendar.html (Denmark)
and alternative mirror http://www.pauahtun.org/CalendarFAQ/ by Claus
Tøndering. He notes all the date formats &c.

RJ

Ranjan Acharya 905-634-0844 x 238 (V)
Team Leader - Systems Group 905-634-9548 (F)
Grantek Control Systems http://www.grantek.com/
[email protected]
[email protected]
 
Thread starter Similar threads Forum Replies Date
H General Automation Chat 8
C Human Machine Interface - HMI 3
C General Automation Chat 0
K General Software Chat 1
H General Automation Chat 2
Top