Stan after Stan after Jerry:

>> As you know, no version of IMAGE offers a 'date'
>> native data type.

>Make that "No HP 3000 version of IMAGE".  I seem
>to recall IMAGE/1000 had data type(s), *years* ago!

>I've been agitating for slew of date data types, to correspond
>with the date types supported by the new Date intrinsics!

>er, make that: IMAGE/1000 had date data type(s).

Just for reference, at the SIGIMAGE meeting at IPROF-97
last spring we had an extended discussion on the subject
of DATE data type(s) in Image/SQL... And we were all over
the map (some people suggested we ran *way* off the edge
of *any* map);  did not reach consensus or anything close to
it.  Then at HP World - Chicago I believe we had 100 percent
agreement among the people in the room (or at least very
close to it) that if there was going to be just one Image/SQL
DATE data type, it should conform to the SQL date / time
standard.

Having just one Image/SQL DATE data type goes along with
the idea that because there are so many valid, semi-valid,
and totally screwy date conventions out there, trying to handle
all or even most of them with a large variety of data types within
Image/SQL itself would be a large effort;  doing just one would
be significantly easier.  Of course that would leave users to do
their own conversions in to and out of that one data type.

If HP was going to implement more than one DATE data type
directly in IMAGE, best idea I've seen so far (just my personal
opinion) is still the one Stan proposed at IPROF-97:  DATE(nn)
, which would allow for 00-99 = 100 different DATE (or maybe
even other types) of data types.  Once the DATE(nn) convention
was established, then it would hopefully be relatively easy to
add new variations as needs and requirements changed.... With
the incredible diversity of data that people loosely refer to as
"date" information, I sometimes wonder if DATE(nn) would be
enough;  it might have to go to DATE(nnn) !!...

In any case, per the HP "State of the Product" at SIGIMAGE -
Chicago, after getting several major new enhancements out to
the user community (B-trees, bundled 32-bit ODBC, Master
Dataset Dynamic Expansion (MDX), multiple PUT-DELETE
semaphores, and QUERY B-tree support) the next set of
features that HP will be focusing on will include "mitigation" of
the 4 MB Transaction Manager limit and additional scalability
enhancements.  Also keep in mind that with the recent formal
commitment by CSY to 64-bit MPE, I believe it is reasonable to
assume that the HP R&D Database Lab will have a significant
number of issues to attend to in that area (but note that far as
I know HP has made no specific comments on that;  either on
or off the record).

So delivery of any kind of Image/SQL internal DATE data type
does not appear to be on the short-term horizon.  If and when it
gets implemented will probably depend on a variety of factors:
Where it shows up on the SIGIMAGE '98 Enhancement Ballot,
discussions at IPROF-98, and whether or not user-financed
enhancements become a reality in one form or another....  In
other words, stay tuned....

Ken Sletten
SIGIMAGE Chair