Glenn,

Points well made!!!

I like your idea on storing the pivot point in a database.  The only
potential problem this might introduce would be in added overhead.  If the
routine needed to check this DB entry every time a date call was made,
substantial time would be spent performing this task -- unless this value
was retrieved in an initialization call and passed into all subsequent
calls...

Thanks,
Gordon Helm
==============================================
G. R. Helm, Incorporated          Year 2000 Consulting Srvcs.
4993 Golden Foothill Pkwy, Suite 1       HP 3000 Specialists
El Dorado Hills, CA  95762                            (888) 665-9065
[log in to unmask]                          www.grhelm.com
Designers of TimeShift 2000(tm)               Date Analysis/Aging
==============================================


-----Original Message-----
From:   [log in to unmask]
[mailto:[log in to unmask]]
Sent:   Friday, April 24, 1998 3:19 PM
To:     [log in to unmask]; [log in to unmask]
Subject:        Re: [HP3000-L] Y2K strategies (long)

Gordon Helm writes after me (and thanks for the feedback!):

> Two additional benefits from [implementing date windowing in a library]
> are gained also: 1) should the pivot point (the value used to determine
> the cut over from one century to the next) ever need to be changed, which
> at some point it will, it simply becomes a matter of an XL/SL update (or
> even less - the changing of a system VAR value)

This changeover is only possible when it is guaranteed that no existing
dates are "older" than the new pivot point.  That is, the year range
(not just the date range) must be less than 100 years before it can
be moved.

> Windowing has the benefit of allowing many
> applications to remain unchanged (e.g. - reports that include date
> information but do not sort this information, user interface screens,
> JCL prompts, etc.)  Plus, what do you do when you need to restore data
> from a year ago because a customer (or some government agency) wants you
> to produce some existing report using this pre-expanded data?

Interesting thought, current reports on old data.

Even if you produce reports using "pre-windowed" data, you must
either set the "window variable" to allow the current 1900-1999
range, or modify/restore the library routine(s) to use said window.

Of course, this is just as critical once the pivot point has moved.
In fact, for this reason alone (What was the pivot point for this
database?), it may be a good idea to store the pivot point in the
database itself.  If the app cannot find the pivot point in the
database, it assumes 1900-1999. :/

>>Assuming that the date is stored in six bytes (a HUGE assumption, IMHO),
>>it covers a myriad of alternate formats that fit in the same six bytes.

>I am sure many of them are functional solutions, but what about the "human
>element"?   What happens when a user, support technician, or programmer
goes
>in with some utility (e.g. - Query), looks at the date in its 'raw' form
and
>decides to 'correct' it since the compressed data looks invalid??  Or,
worse
>yet, corrects them all since they all are out of 'whack'?

Great question.  In this scenario, there would either have to be a heavy
emphasis on training, or--preferably--updating would happen *only* through
apps that support the new format.

> Bemer's idea is to work below that-at the level
> of object code.  Though a number of large companies are skeptical, Bell
> Atlantic is testing Bemer's proposal.  (New Yorker 12 Jan 98)
[snip]
>You may also want to review the article "To the Mainstream Press: Get a
>Clue" in the Nov/Dec issue of the Year 2000 Journal for some commentary on
>Mr. Bemer's solution...

Thanks for the pointers, Gordon!

--Glenn Cole
  Software al dente, Inc.
  [log in to unmask]

.......................................................................

Item Subject: cc:Mail Text