Re: Passing *varsize parameter to another procedure

Sigh... I guess there is no magic api/keyword for this type of stuff.

I don't have an internal procedures. I've two export procedures. One
does that actual task. The other has more bells and whistles but does
not have code to perform the actual task. It simply calls the other
procedure to perform the actual task.

These procedures have a few optional/omitable parameters. It is painful
to convert them to call yet another internal procedure that perform the
actual task. I sure wish RPG can just auto set the address of optional
parameter to null if not passed by the caller. Sigh...






"Scott Klement" <rpg400-l@xxxxxxxxxxxxxxxx> wrote in message
news:<mailman.1539.1225472921.13295.rpg400-l@xxxxxxxxxxxx>...

Hello,

Understand, I normally prefer to use OPDESC to figure out the length
when possible. Why make all the callers do the work when there is a

way

to figure it out internally ;).

I'm trying to understand the scenario... I'm envisioning that you
have multiple "exported" procedures available to the caller, and all
need to call an "internal" procedure and pass this data on to the
internal procedure.

The problem is, when you call the internal procedure, RPG populates

the

OPDESC with what THAT PROCEDURE knows about the variable instead of

what

the caller provided in it's opdesc. So if you have a 32k VARYING, it
passes 32k as the length, even if the caller only told you it was 4k.
(For example)

So... why use an OPDESC when calling the internal procedure? Why not
retrieve the length in the caller, and pass it as a parameter to the
internal procedure? Since that procedure is never called directly

from

the outside, there's no extra effort required by the caller. The

extra

effort is only required internally...

The alternative (and the way I usually do stuff like this) is to use a

VARYING string. Then RPG passes the length in the first two bytes of
the string itself. If you want callers to be able to pass a

non-varying

string, use CONST on the parameter, and RPG will automatically

transform

it to a VARYING and automatically set the length appropriately.

The disadvantage is that you can't use that for RETURNED values. For
returned values, I'd use the OPDESC approach instead, as outlined

above.

Unfortunately, that also means you need multiple front-ends if you
want to support both fixed-length and VARYING...