DIYbanter - View Single Post

Edward Reid

On Sun, 03 Oct 2010 18:57:17 -0400, wrote:
The trafic signal scenario? Extremely easy to get around. The calendar
repeats itself on a very predictable schedule - so for the rest of the
lifespan of the control system a simple reset of the date to a year
with the same calendar, in the same point of the schedule, is all that
was required.

Sure, as I said, lots of times the fix was easy. It was the analysis
that was hard. And in your example, the analysis had to determine that
the kludge that you propose (and it's clearly a kludge, not a fix)
wouldn't cause any undesirable side effects. Kludges have a nasty
habit of causing unforeseen problems. In addition, it could not wait
until 2000-01-01, because too many systems would have needed attention
all at the same time. Many simple ones could have been repaired
quickly after they failed, but many failures appearing all at once
would have overwhelmed the capacity to fix them.

There was a whole lot of money made by "y2k analysts" that was a pure
rip-off - call it fraud to be accurate - and a lot of fearmongering.

No doubt. The DP/IT profession is as rife with opportunists and
incompetents as any other. That doesn't mean that everything done is
opportunistic or incompetent.

The only place it really ended up being any kind of an issue was on
mainframe actuarial systems (big insurance companies running large
databases on antiquated systems running Fortran, as an example)

That's an extremely limited view of what happened. And in any case,
ten years ago those systems ran an awful lot of what was important to
business. It's dropped a lot today but hasn't gone away. Oh, and
insurance companies seldom used Fortran. They mostly used COBOL. I
haven't heard any recent figures, but I suspect that there's still
more production code written in COBOL than in any other language.
Fortran code was generally less of a problem due to its emphasis on
numerical work.

Most of these systems had already oulived their design lifespan -
having been programmed in the '60s and '70s, with the expectation that
they would be replaced in the '80s or '90s.

But they hadn't been replaced. That's part of the point. The other
point that I make, though, is that they were not designed with any
such expectation. They weren't designed with a lifespan at all. In the
60s and 70s, programming on this scale was still so new that
programmers weren't thinking about how long their code would last at
all.

Edward