RE: Multi Occurrence Data Structure returned from a procedure -- RPG400-L

Hi Alan,

Returning pointers from a service program or external routine isextremely bad form no matter what. The only time that I find itappropriate is where it must be returned as with aUSPC_GetPointerToUserSpace.

I agree with you that you should not return pointers in situations wherethe calling routine is expected to interpret the contents of the memorythat it points to.

However, by the same token, I don't think returning a pointer to a userspace is a good idea, either!! The calling program shouldn't need to knowthat you've stored your data in a user space, or dynamic memory, or afile, or anything else -- all of that should be transparent to the caller!Returning a pointer to a user space is every bit as bad as returning apointer to allocated memory or to a static variable.

Unfortunately, in the case of MODS, there's no other way to pass them fromone procedure to another. So, if you MUST pass a MODS, that's how you haveto do it. Though, I agree that replacing the MODS with multiple calls toa procedure is better, if it's possible.

The one place that I do allow returning a pointer is when the pointer is"opaque". In other words, the caller doesn't need to know what it pointsto, what the format of that space is, how big it is... it doesn't have toknow anything about it. Although I know that some people on this listwon't agree with me, I don't think an opaque pointer is that bad. It'scertainly better than returning a data structure (which is the workaroundthat I've seen many people do)

For example, let's say you're creating a service program that works withan order. You want to use a pseudo-object-oriented approach. So you dosomething like this:

         x = order_new();
         order_load(x: 'SA12354');
         order_setShipTo(x: 'Scott Klement'
                          : '123 Sesame St'
                          : 'Milwaukee'
                          : 'WI'
                          : '53201' );
         order_save(x);
         order_destroy(x);

In the code above, X is a pointer. The "ORDER" service program containssubprocedures called "order_new" "order_load" "order_setShipTo", etc.Inside that service program, it points to a data structure that containsall of the per-order state information. That way, the srvpgm can bewritten to allow many different "order objects" to be created at once.

To encapsulate this, order_new() allocates space for the DS, and returnsthe pointer. The caller doesn't know what the format of the memory, thesize of the allocatation, etc are. All it knows is that this is a "handle"that it has to pass back to the other routines in the order srvpgm.Obviously, order_destroy() frees up that memory.

That way, if I need to add more stuff to the ORDER srvpgm's datastructure, I can make the allocation bigger, add fields, etc, withoutbreaking anything.

I consider this approach to be acceptible. Now, I know someone is goingto reply to this message and tell me that I should use a numeric handleinstead of a pointer. And, I don't disagree, but I don't think thepointer method is bad, either. If someone is foolish enough to examinethe memory that the pointer points to and try to reverse engineer the datastructure, they deserve their fate when an upgrade breaks compatibility :)

But, for sure, in a situation like yours where people are returning apointer and expecting the caller to interpret the memory, I think that's abad idea, and should be nipped in the bud.