Re: Optional parameters in CLLE

On Wed, 2017-03-15 at 23:33 +0000, Roger Harman wrote:

I have a couple of processes where I'd like to have one or two optional parms.

In the past, I've just tried using them in a CHGVAR and monitor for MCH3601.

But... I'm wondering if %address() can be used instead. I think it would be cleaner. In my testing, I've seen hex zeros for the %address of a non-passed parm. That seems to indicate a *NULL will be returned. Since it's consistent and not a garbage address, I would think I could count on that logoc.

Does anyone know if this is a documented behavior? I haven't found a definitive answer.

Helge Bichel has given a good answer as I was typing...

I wanted to say, that is not advisable to trust a monmsg or the address
of a parm as it may not contain what you think/assume it does.

A good example is given by Scott Kelement (RPGLE but...):

http://article.gmane.org/gmane.comp.lang.as400.rpg/69232

My guess at why this "bug" happens is that to speed up call stack
processing when a program returns it doesn't bother to *null entries on
the parm "stack" space (parms, if I recall correctly as its been a
while, are pointers to pointers to data) and this may be further
compounded by the "parm pointer stack space" (for want of a better
description) being re-used (by multiple programs at any time) or
bleeding into other data. Nothing is guaranteed.

It may be that CEETSTA is just a long winded "if %address of parm =
*null" or it may be that CEETSTA is checking some hidden value or is
part of a compile time function (like %parms), but better to use the
provided tool than assume a test will always work even if it currently
does the job.

Thanks.

Roger Harman
COMMON Certified Application Developer - ILE RPG on IBM i on Power

Jon.