Re: Reissue the API or Store the Results in a User Space?

Hmmm...  QUSRMBRD returns it's results into a variable, not a user
space.   So why not just pass the variable as a parameter?

If you share the user space among different procedures/modules/programs,
you create an "order dependency" because you have to make sure you
populate the user space prior to running anything that uses it.

Also, I've always felt that when you have multiple procedures/modules/programs
that call either other, the interface between them should be clearly
defined.  I.e., the parameters shoudl clearly define what data is going
into and coming back out of each call -- there should not be another
"hidden" way of passing data back and forth, and to me that's what your
user space represents.

Of course, if you called the API again each time you could do away with the
"hidden interface" as well as the "order dependency".  But then it would
be a question of performance.

So, I guess if there's an easy to way to pass the data as a parameter, I
would do it that way.   If not, I'd call the API each time, since I don't
think QUSRMBRD carries much of a performance penalty.  If you do need to
use a user-space, I would do something like pass the user space library &
name as parameters, so that the interface isn't "hidden".  But, in this
case I don't really see why you need a user space at all...

On Fri, 12 Jul 2002 bill.reger@convergys.com wrote:

> Within a single application, I have fix or six different RPG
> modules/programs that all need to access the information returned by the
> "Retrieve Member Description" API (QUSRMBRD).
>
> For performance resons, would you suggest that I issue the API one time,
> store the results in a User Space, and have each module/program go at the
> User Space?  Or is the performance advantage so miniscule (or worse!) that
> you would suggest that I simply allow each module/program to do it's own
> API call?
>
> Bill
>