|
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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.