Re: Adding parameters to procedures

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

This is a really bad idea.  You may as well use CALL/PARM and *ENTRY 
PLIST, you're throwing away all of the value of using prototypes by 
passing these data structures.

Your code guarantees that all callers (whether they use the new fields 
or not) must be recompiled every time a data structure changes, 
drastically increasing the amount of maintenance that's required.

Even worse, the compiler won't protect you against passing the wrong 
data structure.  You can have a completely different data structure in 
one program and pass it to the other, and there won't be any errors. 
It'll just let it happen, causing all sorts of nasty problems.

Yet worse than that, the subprocedures in your service program have no 
way to detect that they're passed the wrong length parameters.  If you 
add a new field to a data structure and forget to recompile a caller, 
you won't get any errors, you'll simply write into undefined memory, 
potentially corrupting other parameters, in the same or different 
programs.  Just a really, really, bad thing to do.

Why not pass individual parameters?  Why do you want to pass data 
structures?


David Foxwell wrote:
> We are looking at the possibility of standardizing our procedures in
> the manner described at the link below.
>
> The aim is to avoid touching any procedures that don't use a
> parameter that has been added to an exported procedure. We just
> recompile everything.
>
> Each procedure uses a DS for entry and another for output parameters.
> If a new parameter has to be added it is just added to the DS in
> question.
>
> I have a problem with this : it gives rise to horribly long parameter
> names ( I've simplified in the example) and debugging is annoying. 
> But my biggest concern is what else are we missing? Someone out there
> MUST have already tried this system.
>
> Any comments would be greatly appreciated.
>
>
> http://code.midrange.com/index.php?id=703f46126a