Michael:
My reply to your original posting was in reference to your example of
comparing two dates. In that case the 2 solutions are comparable.
However, no one solution addresses all the problems associated with
the year 2000. Every Year 2000 case is unique and must be handled
with whatever tools make sense. Sometimes it makes sence to
completely change data and programs to 8 digits. Sometimes an
intermediary data conversion process works effectively. Many times
a combination of the two are what is necessary.
What I was trying to point out is that there are some very good
solutions to many of the year 2000 problems available on the HP
3000. However, let me address the issues you brought up.
On, Wed, 5 Nov 1997 15:13:09 -0800, Michael Berkowitz
<[log in to unmask]> wrote:
>Let me see if I've got this right.
>
>1. Millennium Rx intercepts DBGET and passes an 8 digit date
>where a 6 digit date resides.
That's only one of the functions handled. It also intercepts DBPUT
and DBUPDATE allowing for conversion from 6 to 8 digit dates, 8 to
6, or 6 to 6 (001030 to A01030, etc). Internal and external sorting
problems are also handled.
>2. User must change all application Image buffers to 8
>characters to accommodate the longer item.
The products purpose is to only have to change the data elements
within those programs where the logic is such that the program will
not work correctly for the year 2000 and beyond. Why fix what isn't
broken?
>3. Since the item is now 8 characters in the user's application,
>all other variables that compare to this now longer date must also
>go to 8 characters. If this data is then written to another file or data
>set or VPLUS screen, then either this file or screen must change
>size to hold the longer field, or you must change your code to only
>pass 6 characters.
That's correct for the program that needs to be changed. If
subsequent programs that use passed data also need 8 digit dates, then
yes, the passed data, and those subsequent programs, must also be
changed. If a particular date is used in such a way that many
programs need to be changed to work with an 8 digit date maybe this
is a case where the data should be changed to 8 digits, and all the
appropriate programs should be changed. Of course, after you've
converted your data to 8 digits, you could convert the 8 digit to 6
digits for those programs that do not need the 8 digit date.
>4. Millennium Rx only works on Image, therefore KSAM, flat
>file, Allbase, Oracle or internally calculated dates get no help?
Yes, at this time the database capturing portion of the product is for
IMAGE database applications. However, Sort2000i & Sort2000x
handle application sorting issues, regardless of where the data is
stored.
>5. What about report writers and general inquiry tools such as
>Query, DataExpress, Inform, ODBC, etc. They do a DBINFO call
>and determine the field is 6 characters, but 8!! are returned. Ay
>caramba they'll say.
If applications in these languages perform logic that needs 8 digit
years we can't help. However sorting issues are handled.
>6. You only have to change all your job streams, user >menus,
>udcs, command files and application embedded program runs to add
>an XL=3D"MILLENNIUMXL" clause.
Only those programs that need to convert to 8 digit dates need the
"XL=" clause.
>7. Somehow you must determine that a field is a date for
>Millennium Rx in the first place.
If it's defined as a date field, either in IMAGE or in the sort, we will
automatically take care of it. Otherwise, the user has to define the
date fields for us.
Also as a note to the general population out there, I'd like to know
what cases we don't handle. Our philosophy is to add tools to the
suite to handle as many problems that makes sense. I like the idea of
having the compiler internally handle the problem, as in the IBM
case. However, we are sorting and IMAGE experts and know very
little about compilers.
Gordon Croston
---------------------------------------------------------------------
Genesee Software,Inc.
7977 South Wabash Court (303) 850-9128
Englewood, CO 80112 (303) 771-0717 fax
[log in to unmask]
---------------------------------------------------------------------
PostHaste, MailMessenger, MailEmpower, MillenniumRx, Monarch
|
