Re: Year 2000

John,

In a message dated 97-06-07 13:33:55 EDT, you write:

> >Doing a Y2K conversion AND converting to ILE is a bit ambitious, don't you
>  >think?  It was my understanding that there were some performance problems
>  >with the date data types at one point, is this still the case?
>  >Regards!
>  >Dean Asmussen
>  
>  To heck with the performance issue.  I bet the files you have to day, You
>  (and more importantly) and your users will be using well beyond the year
>  2000.  They will be using(or wishing they could) Date type functions 
>  (durations, etc) even MUCH more 2-3 years from now than they do today.  

How well do these date functions work with a 3rd party EIS?  My point was
that eight digit dates are transparent to tools, regardless of the source.
 The performance issue was an afterthought to which I hoped (and have yet) to
receive a response.

>  What if IBM 2 years from now made the date performance FANTASTIC.
>  You wouldn't be able to justify converting then could you. 
>  The whole Y2K issue is a testimony to the great forsight and planning
>  us IS professionals have had.  By implementing 8 byte numerics we 
>  (IMHO) are continuing in that grand tradition.

We seem to have touched a sore spot here, haven't we :-)?  Again, I was
seeking clarity for EIS's, NOT native applications.  If we're already
converting six-byte dates in our applications, how much harder is it to
change those routines to handle eight bytes vs. using date built-in
functions?

>  IF you don't make them native date & time data types now you NEVER will.
>  We started using them on V2R3 even though we had to use them in RPGIII. 
>  When we got RPGIV guess what,  Alot of our data base was ready for it.
>  We didn't think about the pain of RPGIII, we thanked our selves for
actually
>  PLANNING ahead.  The users who use Query/400 to Slice/Dice THEIR data
>  and then use file transfer to put it in a graph tool on the PC
>  also thanked us for the ability of doing Date math.

So the date fields work better in Query?  That's sort of what I was asking.
 A^lot (notice the space) of people really don't know the pro-con's of using
date fields, and a lexicon of these was what I was looking for.

>  ITS NOT JUST OUR DATA anymore.
>  
>  Let me see a user subtract (easily without converting to virtual fields)
>  one 8 byte numeric date from another using Query/400 to come up with a 
>  date duration.

Exactly what I was asking.  Does this work as well in FOCUS or ShowCase?

Regards,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-Mail:  DAsmussen@AOL.COM

"In America, anyone can become President.  That's one of the risks you take."
-- Adlai Stephenson
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List!  To submit a new message,   *
* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
* this list send email to MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
* should be directed to the list owner / operator: david@midrange.com   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *