Re: Passing a Null Date to a Procedure

On Thu, Dec 31, 2009 at 3:44 PM, Scott Klement
<rpg400-l@xxxxxxxxxxxxxxxx> wrote:

Hi Charles,

Your second option of building the DS is also too cumbersome for me.
(Again, this is just my opinion)

  d parm1               ds       likeds(NullableDate_t) inz(*LIKEDS)
  d parm2               ds       likeds(NullableWhatever_t) inz(*LIKEDS)

      parm1.value = FILEDATE;
      parm1.isNull = %nullind(FILEDATE);

      parm2.value = whatever;
      parm2.isNull = %nullind(whatever);

      MyCoolProcedure(somedata: parm1: parm2);

For sure, it's not nearly as ugly as the *OMIT scheme, but it's still
too ugly...  and with this scheme, if the parameter can be used for
output, you have to move the data back afterwards...

Hi Scott,

While I agree with you about the use of *OMIT, I have to disagree with
you about the use of the DS. It's not as ugly as you seem to think.
The example doesn't show it very well since it is so short, but the
idea is that rather than using a simple date variable in your code you
define your own "nullable date" type and use that. Thus, the only
place you need be concerned about moving the data between the
structured variable and the simple variable is when the file is
read/written.


Consider:

d myDate ds likeds(NullableDate_t) inz(*LIKEDS)

myDate = GetDate();
MyCoolProcedure(myDate);
WriteFile(myDate);

vs.

d myDate s d
d myDateIsNull s n

GetDate(myDate:myDateIsNull);
MyCoolProcedure(myDate:myDateIsNull);
WriteFile(myDate:myDateIsNull);


IMO, it makes sense to have DS explicitly tying together the date
field and the null indicator. You lose a little bit of flexibility
since you can't pass literals into the procedures, but that to me is a
small price to pay.

Charles