RE: Remember Y2K?

[qsrvbas@xxxxxxxxxxxx (Tom Liotta)]

midrange-nontech-request@xxxxxxxxxxxx wrote:

>   2. Re: Remember Y2K? (rick baird)
>
>I cut a fair amount of Y2K fixes, but the thing I discovered was,
>unless there was a sort on year, or some date math involved, use of 2
>digit years might look ugly or cause an anomaly here or there, but
>mostly they were just informational - just another field to print on a
>report or display on a screen.


Completely agreed. But date-math/sorting is precisely the area I was focusing 
on.

I too did a bunch of Y2K work, becoming very familiar with less common bits 
such as SAVSTG and its related restores along the way in order to facilitate 
all the test runs.

The app I had in mind was date-driven in major ways. It was bungled together 
around a set of document work-flow procedures that included date-driven trigger 
events. E.g., six months prior to a given date in the case, a notice is posted 
that causes actions.

But it wasn't "exactly" six months -- it was more like 'for every case with a 
date that is less than six months in the future from the current system date, 
i.e., when this job is run, post the notice'. Because it's a date comparison 
for greater/lesser, the potential for chaos in that department was high once 
6-digit dates started crossing the 1999/2000 boundary.

That is simply a single example, one that stuck in my mind. _ALL_ of the dates 
that sequenced work-flow were handled similarly and the work-flow was a 
multi-month process for every case in the app.

I'm pretty sure that the majority of dates in apps in other divisions were 
similar. A lot of government agency kinds of apps are tied to such date 
triggers. And I have no reason to think that divisions in other state 
Departments there were any more prepared, particularly those that couldn't even 
go past Win3.x much less Win95 as their primary interface to back-end databases 
that were written with 6-digit years.

Wish I could've stuck around so I'd have a clue how much ended up being covered 
up in terms of _real_ cost beyond budgeted cost.

Tom Liotta