Re: Passing a Null Date to a Procedure

I understand Scott and as always appreciate your input......

The issue is do I make one or two calls or create an additional object to
use for the D spec work around....

One date will get passed in for sure from the caller, as far as the two
other dates (which are the only ones that can truly be NULL) the caller
really does not need that information per se.





From: Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
To: RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
Date: 12/31/2009 01:43 PM
Subject: Re: Passing a Null Date to a Procedure
Sent by: rpg400-l-bounces@xxxxxxxxxxxx



To me, that's more of a question of "whose job is it", and less of a
question of performance. Determine which routine SHOULD be responsible
for supplying the date... should the caller even know or care that
there's a date involved? That sort of question is how I'd decide which
routine retrieves the record.

Sorry, I don't know enough of your environment and application to give
you a more direct answer.

But... options(*NULLIND) does let you pass the null indicator. :)


Doug Palme wrote:

Hey Scott,
A thought just hit me, what if I passed in the keys for the data in the
original file, did a chain and then tested for the *NULLIND locally in

the

procedure?

The only difference is I am adding some overhead for the file lookup

local

to the procedure.

Thoughts?




From: Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
To: RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
Date: 12/31/2009 12:36 PM
Subject: Re: Passing a Null Date to a Procedure
Sent by: rpg400-l-bounces@xxxxxxxxxxxx



Hi Doug,

You need to declare options(*NULLIND) on the prototype. When you do
that, RPG will automatically pass the null indicator with the parameter.

However, bear in mind that it's not possible to declare a field on
D-spec with a null indicator. That means parameters passed to this
subprocedure have to be externally defined variables coming from
null-capable PFs declared on an F-spec. That severely limits the
reusability of your subprocedure. Personally I would give that a lot of

thought before using options(*NULLIIND)



Doug Palme wrote:

Is there any way to define a date value in a procedure interface as

being

null capable?

I have checked the reference manual and so far have come up empty

handed

on this.

We have a file that allows for null capable dates and I have to pass

this

value to a procedure for some processing, but it does not like the

usage

of the %NULLIND parm.

*RNF0342 20 3 The parameter for %NULLIND is not valid; %NULLIND

is

ignored

*RNF0342 20 259 008812 Parameter WENDDATE for %NULLIND is not null
capable
%NULLIND is ignored.

Suggestions?

Douglas