Re: Adding parameters to procedures

Thanks to all for the input I've received on this subject.

Unfortunately, I seem to be losing the battle and it looks like all our
exported procedures will systematically have 2 DS :
One containing the input parameters and the othe the output parameters.

The DS are described with the prototype for the procedures, and the caller
uses /COPY to integrate them. Each time a procedure is modified, all the
programmes using the module are recompiled. The response is that this way
there is no danger with passing the wrong parameters.

So, it looks as though we are saying no thanks to prototyping and all the
other features available on individuel parameters.
I wonder what IBM would do with RPG if everyone stuck their 2 fingers up at
them like this.

I would greatly appreciate anymore help on this subject..

We are also looking at separating all our DB loqic in one module for each
file. All actions on a file would be by a procedure with, you've guessed it,
an input DS with the key and and output DS with the whole record.

Is this a good idea?
How is it different from the way Scott does things in his article on MVC?
(iseries news feb 2007).



----- Original Message -----
From: "Scott Klement" <rpg400-l@xxxxxxxxxxxxxxxx>
To: "RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
Sent: Monday, June 18, 2007 9:10 PM
Subject: 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

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.