On Thu, Apr 23, 2015 at 9:48 AM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:
My one and only contribution to this thread is to remind people that
what is 'short-sighted' in 2015 was deliberate and intelligent in 1975.
What was deliberate and intelligent in 1975 was not necessarily still
intelligent in 1998 and 1999. Companies that needed to fix their
systems for Y2K were going to have to invest a lot of time and money
no matter what. I'm sure a lot of companies picked a kick-the-can
approach that turned out to be not *that* much cheaper than what a
"proper" solution would have cost.
Also, some companies *did* plan ahead, and were Y2K-ready well ahead
of time (like in the mid-1990s or possibly even earlier).
Having established that there was an actual reason for recording only 2
digits, it is not much of of a meander down the cow path to what we
have to deal with today:
We now have a
hodgepodge of date logic throughout our system.
At some point I realised that this is the natural state of software [...].
It's absolutely true, that that's the natural state of software. It's
also absolutely true that there were very, very good reasons for
2-digit years. (No need to invoke punch cards; memory and disk
storage were legitimately expensive and scarce for much of my
computing career.)
But I am still very comfortable saying that many, many companies made
flat-out *shortsighted* decisions regarding Y2K. See, most problems
are either completely unexpected, or there is a vague, fuzzy sense
that "oh, that *might* become an issue *sometime* down the road". Y2K
does not fall into these categories. Everyone knew it was coming, and
everyone knew exactly when it was coming.
Now, I'd also like to clarify something regarding my post:
On 4/22/2015 11:22 PM, John Yeung wrote:
So, to address one of Dan's questions, about sliding the window, even
if IBM provided a system setting for this, it wouldn't make a
difference at some shops. Our Y2K problem had absolutely zero to do
with anything provided by IBM. It had everything to do with
shortsighted database design and application logic.
When I said "our Y2K problem" what I meant was "the Y2K problem
specific to the company that I work for". You see, we didn't merely
have garden-variety date problems. We had worse-than-average date
problems. Dates weren't working very well here even before Y2K was on
the horizon. It's not that our database was designed under outdated
resource constraints or sensibilities. Our database would not have
been considered sensibly designed on any system, in any era. It was
really just... bad. Now, I'm sure there were some other companies as
bad off as us, or even worse. But we were definitely in the wrong
pointy end of the bell curve.
John Y.
midrange.com
