Re: RPG IV program - comments requested -- RPG400-L



Peter Dow wrote:

> > The procedure interface is the equivalent of the *ENTRY PLIST with the
> addition
> > that the compiler will validate it. The validation is performed by
> comparing the
> > definition of the procedure interface (PI) against the definition in the
> > prototype (PR).
>
> Isn't that like having to enter your password twice? Although in the case of
> a password, one can excuse the redundancy because you can't see what you're
> typing. Putting the same exact code in two places so that one can be
> validated against the other?
>

Not quite the same. You are making the assumption that the PI is correct. The
compiler wants to validate it and it validates it against the PR.

>
> > On the same basis, in a calling module the compiler will validate the call
> > statement (CALLP or EVAL) against the definition in the prototype. Hence,
> since
> > the prototype will be required in many modules (each calling module and the
> > module in which the called procedure exists) it is best to have only one 
>copy
> of
> > it and include it where required, using /COPY.
>
> Now this I can understand as a way to prevent run time errors (although I
> certainly hope it doesn't mean they don't do parameter checking at run
> time -- what if the called procedure's interface changed?)
>

Sorry, they don't do parameter checking at run time, no more then they did with
dynamic calls in RPG III.
If the PI changed, one would have to change all modules that called it. The
simplest way to do this is to change the /COPY member containing the prototype
and re-compile all modules that contain the relevant /COPY. You will now have
every line that needs to be changed highlighted.

>
> > The reason that the compiler does not look at the called program is that the
> > called program may not yet exist. The validation is performed on the
> CRTRPGMOD.
>
> Ok, that makes sense to me too. Thanks!
>
> > I amn't quite sure that the version of the /COPY is an issue. If you are
> using
> > the wrong version, the module will not be created.
>
> Why is that? As long as every CALLP or EVAL conforms to the prototype in the
> /COPY, the compiler will be happy. And you just said it doesn't check the
> program since it may not have been created yet. Therefore, you will only
> find the problem when running the program. Again, assuming that it still
> does parameter checking at run time.
>
> Or wait, have I got that wrong? Are called procedures bound with the calling
> program at CRTBNDxxx time? Are the parameters checked again at this time?
>

OK, now I see what you meant <g>. It does mean that you have to be VERY VERY
careful with the COPY members used for prototypes. Treat them like the DDS for
files. Yes, there is room for improvment in the way this works, but it is still 
a
lot better then what we had.

Have you just been using just CRTBNDxxx or have you also used CRTxxxMOD and
CRTPGM (which is basically what CRTBNDxxx does)? The reason I ask is that a lot
of the binding issues become clearer when you do it as two steps.

>
> I hope I don't sound like I'm arguing about how we have to do it to make it
> work. I'm just trying to understand the reasoning behind it. Having the
> compiler doing some additional checking to make sure the correct size and
> type of fields being passed as parameters is not a bad thing, although there
> is still room for error. On the other hand, in my many years of programming,
> problems caused by passing the wrong parameters have been few in number, and
> usually not to hard to find.
>

Where I come from, this would not be called arguing and you are right, there is
still room for error. You are lucky to have come accross few problems with
parameter lists. There was a thread here a while ago where a program ( in a 
group
of programs ), that had been converted from RPG III to RPG IV, suddenly stopped
working with an error on an internal pointer. Cause was a mis-match on a
parameter list in a earlier call. The bug had stayed hidden for a few years.
Whereas mistmached number of paramters or wrong data types may become fair;y
obvious, see what happens when the last field of the parameter list is defined 
as
50 in the calling program and 60 in the called program.


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---