Print

Print


True enough! I don't remember WWII or Korea.

Discovered probably wasn't the right word, popularized might be better.
I just got out of a meeting..... ;-)

I'm going through Y2k cert now, or rather members of my team are. Our
dates are confined to data tables, but the date section is not used in
processing. Our PC's on the other hand.....

I think my comment about designers not forseeing the future was
misplaced. The designers were solving a problem within a certain time
frame. OK. But aircraft & military projects tend to be longer lived,
"plan for a 20 year lifecycle!" The C-130 is almost 40 years old. 135's
are getting up there too. How do you explain the Y2K errors found in
airliners or military projects that were done 10-15 years ago? What
about processors designed for use in the power grid that are suppposed
to run for 2-3 decades, some placed only a few years ago? Or that pace
maker Aunt Edna had put in 9 years ago? Anything done in the last 15
years should have planned for Y2k, especially critical systems! I think
it has to be chalked up to engineering error that many weren't. We've
known for years that systems live longer than planned, yet in many cases
we just don't worry about it until it's to late.

I agree, planning for Y10K would be rather pointless (anyone planning on
being around then??) It would, however, make sense to design our systems
so that single point failures, like a date calculation, don't shut down
our power grid, ATC, or pace makers. I've read about systems where the
date is ONLY used to log events, and that the logging of events (ala
"Log Status OK") after Y2k can cause a perfectly healthy system to fail.
That's a preventable failure in my book.

But aside from all that, does anyone think that Ada was/is the silver
bullet for Y2K? The original poster has the mistaken idea that Ada can
solve the Y2k issue. That's a dangerous thing for Ada.

That's probably enough Y2k for me today...
I think I'll Abort To Home and see if my PC experiences the 1.5 hour
bug....


John T Apa                              [log in to unmask]
L-3 CSW                                 (801) 594-3382
PO Box 16850                            Fax: (801) 594-2195
640 North 2200 West                     Salt Lake City, UT. 84116-0850



>-----Original Message-----
>From:  C. Daniel Cooper [SMTP:[log in to unmask]]
>Sent:  Monday, March 08, 1999 2:02 PM
>To:    [log in to unmask]
>Subject:       Re: What about a press release
>
>John Apa wrote,
>
>> Y2k is only a problem because it was
>> "discovered", for lack of a better word, late in the game. We've learned
>> that we need to look ahead and write code that won't fail at a
>> predetermined date/time.
>
>John betrays his age -- he must be a younger guy :-)
>
>Being guilty of writing Y2K-noncompliant code 30 years ago myself (for
>different employers), I can vouch that the problem was not "unknown" and
>did not need "discovery" later on: we all knew what we were doing,
>namely, cutting corners to get those programs to run in the teensy
>memories of the day. We knew the code wouldn't work on 01jan2000; what
>we *didn't* know was that our software would still be in use then!
>
>*All* date-based code will eventually "fail at a predetermined date/time"
>-- it's just a question of how far out the failure date is; back then, we
>thought 3 decades was quite long enough. Should we be writing code that's
>Y10K compliant now? :-)
>
>--
>
>C. Daniel Cooper =========v=======================v
>Engineer at Software      | All opinions are mine |
>206-655-3519              | and may not represent |
>[log in to unmask] | those of my employer. |
>==========================^=======================^