Re: Adding parameters to procedures

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