Well, putting the *ISO is something that I had done since the first time I
learned this technique. I think that way back when I learned it I had
some other DATFMT set or something and needed it. However, I think Scott
might have gotten it right when he said that my source didn't match my
object. I don't know why it wouldn't have, but to be save I recompiled
this morning and updated the service program with the new object. All
works well, no matter how I have it coded. With the *ISO, without the
*ISO, and even moving it to a Date variable with/without *ISO before the
loop and using the variable in the comparison (which is the best way to do
it so that I'm not evaluating %date everytime when the date is static).
Sorry for the bother and thanks for the help. But I did learn that I
might not need the *ISO after all. I will test this more as I go since I
use this often.
Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777
Booth Martin <booth@xxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
10/01/2009 06:40 PM
Please respond to
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
To
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
cc
Subject
Re: %date not evaluating in DOW as "I" would expect
Something is going on that is not as expected. My experiences with IBM
stuff is that generally one is better off not be redundant in the
coding. Belt or suspenders, yes; belt & suspenders, never. The
default for %date() is *iso, so why declare it an extra time?
Does this make sense? No, not at all. :) However nothing else has so
far, either.
Scott Klement wrote:
What are you suggesting, Booth? That his zoned decimal date isn't
really in YYYYMMDD format? He says it contains 20091016 -- if it's not
in YYYYMMDD format, wouldn't that cause the program to generate an
exception?
I guess I don't follow your logic, Booth.
Booth Martin wrote:
I've been wondering if he could just leave the *iso parm off the
%date(bif) (unless he has set a DATFMT keyword) and see if that works
as
he expects?
midrange.com
