RE: Date compare Best Practices

And to make your item #4 even more clear:

  dYMD = %Int(ds.yyyy + ds.mm + ds.dd)
(Assuming yyyy, mm and dd are character subfields.

True date data-type manipulation has _always_ sucked. We had a conference
call with IBM Rochester about it back in the V3R7 days as Y2K was
approaching.
The fundamental problem is that the people who own (owned?) date data-types,
are arrogant and self-righteous and won't improve performance or change the
implementation because "That's the way it works."  It is probably still true
that every time a data field is touched, it is converted from the internal
form to the external or from the external form back to the internal form. So
in your Item #1 example, how many times does that code "touch" the date
field internally? That might explain the performance issue.

-Bob

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Hans Boldt
Sent: Friday, February 27, 2004 8:50 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Date compare Best Practices

Bob Cozzi wrote:
> Actually Hans, that's not it at all.
> If I have a display file with one or two date fields in it (and we're
> talking RPGIII here) I would rather write two MULT and get it done than
> worry about setting up a DS in RPGIII and moving the bytes around. 
> If I were reading say 100,000,000 database records and converting a date
> field in them, then I would probably use the DS method.
> -Bob

Bob: You might find this hard to believe, but I think I've changed my 
mind on this issue.

First, consider performance. Sure, doing a couple of subfield moves is 
faster than using the MULT trick. But the MULT trick is still ~35 times 
faster than doing things the proper way, converting to and from a date 
value!

Second, and perhaps more importantly, consider code readability. Sure, 
seeing a MULT by 100000.0001 (or whatever) is cryptic. But so is a 
sequence of moves. Sure, not everyone knows the "trick". But when it's 
explained, it just becomes another idiom in the language. Much of what a 
programmer does involves learning and mastering language idioms.

That's not to say I will recommend the use of the MULT date conversion 
trick. But I agree with you - I really don't see any reason not to use 
it either when appropriate if you can't do the "right" thing and use the 
date datatype.

BTW, out of curiosity, I did a bit of performance comparison as I was 
putting this note together. Here are the times for equal iterations of 
alternative statements:

#  time  statement
-  ----  --------------------------------------------------
1: 6982: dmdy = %dec(%date(dymd:*iso):*usa);
2: 1038: dmdy = %int(%subst(%char(dymd)+%char(dymd):5:8));
3:  190: C     dymd          mult      10000.0001    dmdy
4:   64: ds.num = dymd;
          ds = %subst(ds:5:4) + %subst(ds:1:4);
          dmdy = ds.num;

Statement #1 is the date conversion done "properly" using conversion to 
and from date type. Statement #2 sort of does the MULT trick but using 
character manipulation in a free-form calc. Statement #3 is the MULT 
trick. #4 converts the date using manipulation of DS subfields.

Clearly, using date data type is the slowest. But also, it would appear 
that the MULT trick isn't nearly as bad relative to subfield moves as it 
used to be.

Cheers! Hans

_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.