Re: Date fields was: Quick question on indicators - more philosophical than anything else

rob wrote:

One person pointed out that certain numbers are useful for meaning things like "no due date selected yet" and other special functions. I argue that you could use a null date or reserve certain dates for restricted usage, like a New Years date from 200 years ago means ...

Not disagreeing with you, but it should be noted that NULL support requires some education. Programmers can no longer just use the date fields without checking %nullind first.

In the old days, we thought nothing of
daysDiff = %diff(%date(): datefld: *days);

If datefld is null, this will get you a CPF5029 at runtime. Now, with null-capable fields, we need to do something like this (actually doing something with daysDiff though, is an interesting decision. What if this is a report?)

if %nullind(datefld);
daysdiff = -1;
else;
daysDiff = %diff(%date(): datefld: *days);
endif;

Then there's the question of passing a null date to a procedure. The natural impulse:

dateTest(datefld);

ddateTest pi
d inpDate d
c/free
if %nullind(inpDate);
dsply 'null';
else;
dsply inpDate;
endif;
/end-free

results in a compile time error, RNF0342: Parameter INPDATE for %NULLIND is not null capable; %NULLIND is ignored. You need to pass the null indicator along and test it separately:

dateTest(datefld: %nullind(datefld));

ddateTest pi
d inpDate d
d inpDateNull n const

c/free
if inpDateNull;
dsply 'null';
else;
dsply inpDate;
endif;
/end-free

None of that is difficult, just an opportunity to educate the rest of your group once you start using null capable fields. The end of Chapter 10 in the RPG Reference has a section on database null value support.

I've never had to explain null values to end-users using their own query support, and have no idea how null values are handled by third party applications like DBU or ASC SEQUEL, but that might be a consideration, too.
--buck