Re: Pointers as Parameters in Subprocedures

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

Hi Brad,

> 1.  I assume the same holds true if you use a parameter to
> return a pointer to local storage in the subprocedure.
>  This is not a pointer passed in, but a parameter used as a
> return value.

It really has nothing to do with how the pointer is passed or whether the
pointer is static. It has to do with when the memory that it points to is
allocated & deallocated from the system.

When a subprocedure starts, memory is allocated for all of it's local
variables.  When it ends, that memory is deallocated.

You don't want to return the address of a variable that's going to be
deallocated.  That memory should no longer be used by your program.

> 2.  Would defining the pointer as static (still local to
> procedure) make a difference in either case (return or
> parameter)?

It doesn't matter if the POINTER is static, it matters if the memory that
it POINTS TO is static.

Conceptually, a pointer is just a variable that stores a number -- just
like a packed field.  A pointer's number happens to correspond to a
position in the system's memory banks... on the iSeries there are some
other things encoded in the pointer as well, but it's still just data
stored in a variable, like any other variable.  When you return that
variable with a RETURN statement, you're copying it to a variable in the
calling routine -- just like with a packed field.  It doesn't matter
whether the one in the subproc is static, because you've copied it
somewhere else and are now using that copy. Likewise, when you save it to
a parameter, you're copying it to the caller's memory.


> 3.  What if the pointer pointed to a global variable in the
> module/service program?

That should work with no problems, since the global variable isn't
deallocated when the subproc ends.