Re: 7.1 and RPG prototypes

That was the point I made John - in the very first sentence of my post (i.e. not the bit you copied).

I said: "When the procedures are in the same source that they are being used in then the PI is used to validate the call. So the validation aspect still exists."

The "same code" would not be in the same source (with the exception noted below**). The prototypes would be in a separate source and /COPY'd into BOTH the defining and using source files.

Let me pose the question in reverse.

Given that your prototypes are in source file X - how would you ensure that they are an _accurate_ representation of the PI?

If they are not accurately validated then it becomes very easy for them to get screwed up. I've seen it happen many times. Programmer A writes a subproc that accepts a 5 digit packed as input. No CONST, no VALUE.

Programmer B adds the proto to his program because he wants to use the subproc. When he tries to use the subproc with a 5 digit ZONED field the compiler complains about the date type. So he "fixes" the problem by adding CONST to the proto. Problem solved! Except it won't always work because the subproc is actually changing the value of the parameter (I know it shouldn't but ...) - when a packed value is used the caller sees any change in the parm. When zoned is used no change is seen.

Bad example but hopefully you get the point. (In my defence it is Sunday and I'm trying not to think about work too much.)

To deal with issues like this the compiler expects the prototype to be included in the procedure source (via /Copy) and as long as any change in the proto triggers a rebuild, the problem will be identified.

** The exception is that some people like to keep the protos in the source file that defines the subproc and use compiler directives to allow only the proto portion to be /COPY'd into the callers.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Mar 4, 2018, at 3:08 PM, John Yeung <gallium.arsenide@xxxxxxxxx> wrote:

On Sun, Mar 4, 2018 at 10:52 AM, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

While a terrific change for cases where procedures are used as building blocks within a program, this relaxation has caused a problem (as discussed earlier in the thread) because there were actually _two_ reasons for using prototypes. The first was to validate the call - the second (in the source that defined the procedure) was to validate that the prototype accurately reflected the procedure interface. With the relaxation in the rules it is no longer compulsory to include the prototype in the defining source and that can lead to errors when some sloppy programmer changes the prototype and does not change the procedure itself.

I'm afraid I (not OP) still don't understand. Why can't the procedure
interface ***BE*** the procedure prototype (in the context of the
source where the procedure is defined). I fail to see how it would
EVER be conceptually necessary to write the same code twice in the
same source.

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

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: http://amzn.to/2dEadiD