RE: Date arithmetic - performance dog?

["Booth Martin" <Booth@xxxxxxxxxxxx>]

In this instance I might do the (test D E ) followed by getting last week's
ending date. If the job date is greater than the last week's date I'd just
add 7 days to the answer already gotten.
 
But beyond that..  why do you do it over and over?  Once at the beginning of
the program would seem plenty.  Get the two ending dates and save them as
test fields.  If job date > last weeks date use this week's date, else use
last weeks date. That'd seem to be your biggest saver of time.
 
 
---------------------------------------------------------
Booth Martin   http://www.MartinVT.com
Booth@xxxxxxxxxxxx
---------------------------------------------------------
 
-------Original Message-------
 
From: RPG programming on the AS400 / iSeries
Date: Thursday, May 15, 2003 8:55:33 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: Date arithmetic - performance dog?
 
That's worth a try. I never even thought of that. Here's an example of
something the program does many times. In looking at it now, I think I even
TEST(D E) endDate further down in the process which makes no sense! The
routine is done thousands of times and the other routine gets into the
millions. Might make a difference. Thank you.
 
 
* test for valid date. 
c test(d e) XQ03 
c if not %error 
 
* if XQ03's week ending date is beyond today, set the week start/end to 
* the previous week's 
c if #getWkEndDate( %date(XQ03) ) > jobDate 
c eval beginDate = #getPrvWkStart( jobDate ) 
c eval endDate = #getPrvWkEnd( jobDate ) 
c move endDate endDate# 
 
* else set valid week start and end dates 
c else 
c eval beginDate = #getWkStrDate( %date(XQ03) ) 
c eval endDate = #getWkEndDate( %date(XQ03) ) 
c endif 
 
* else invalid date, set week start/end dates to previous week 
c else 
c eval beginDate = #getPrvWkStart( jobDate ) 
c eval endDate = #getPrvWkEnd( jobDate ) 
c endif 
 
 
 
 
-----Original Message-----
From: Hans Boldt [mailto:boldt@xxxxxxxxxx]
Sent: Thursday, May 15, 2003 9:12 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Date arithmetic - performance dog?
 
 
Mlpolutta@xxxxxxx wrote:
> I wanted to see if you folks have found that ADDDUR and SUBDUR (etc.), and
MOVEing to/from date fields are REALLY poor performers - it sure seems that
way to me. Is there a way to make such things perform well?
 
The performance of the date/time/timestamp operations is indeed a 
touch on the slow side. The reason is that each operation does a 
validity check on the values.
 
The only suggestion I have is that if you're converting from 
character or numeric to a D/T/Z value, don't check first using a 
TEST operation. Just convert directly using the appropriate built-in 
function (%DATE, %TIME, or %TIMESTAMP) wrapped in a MONITOR group. 
That will at least save one validity check.
 
For example:
 
MONITOR;
DATE=%DATE(DSTR:*YMD);
ON-ERROR 112;
DSPLY 'Egads! We have a bad date value!';
ENDMON;
 
Cheers! Hans
 
.