Share definitions between Prototype and Procedure Interface

Question

I am getting started with RPGLE and I am trying to determine if there is any way of just defining the parameters for the procedures in my service program once. I know I can put the prototypes inside a copy member (which I have done), but then I still have to put essentially the same code into the body of the procedure (the "procedure interface").

My question is, is there some way of using the prototype to define the parameters in the procedure interface (or vice versa)?

Ideally, something like:

Prototype:

D buildForm        PR
D  formType                      10A   CONST
D  mode                           4A   CONST

Procedure:

P buildForm        B
D buildForm        PI
D  formType                            LIKE(formType)
D  mode                                LIKE(mode)

Well, ideally I would just be able to say 'use prototype' or something in the body of the procedure, or the compiler would find it on its own...

Am I misunderstanding how Prototypes and Procedure Interfaces need to be set up, or are they actually this repetitive when done correctly:

Prototype:

D buildForm        PR
D  formType                      10A   CONST
D  mode                           4A   CONST

Procedure:

P buildForm        B
D buildForm        PI
D  formType                      10A   CONST
D  mode                           4A   CONST

Thanks for reading.

score 4 · Accepted Answer · answered Feb 20 '14 at 15:15

On 7.1, if you are defining a sub-procedure in the same program you are using it, you don't need the prototype. You only need the prototype if you're consuming a sub-procedure from a service program or bound module (Don't bind modules to a program!)

I don't personally find the prototype burdensome to create. I copy the PI, change it to PR, put it into a /copy member and use it in many programs like this:

  /copy buck/qprotosrc,buildform
  ...
  buildform(form: mode);

The only time I need to 'double define' is in the service program where the PI is located. A way to avoid most of that is to use conditional compilation. Here's an example:

qprotosrc(buildform)

  // Build form prototype and start of interface
  // Service program will complete the interface with P    E
  /if not defined(buildform_proto)
  /define buildform_proto
 D buildForm       PR
  /else
 P buildForm       B
 D buildForm       PI
  /endif
 D  formType                     10A   CONST
 D  mode                          4A   CONST

qrpglesrc(mysrvpgm)

  /copy buck/qprotosrc,buildform
  ...
  /copy buck/qprotosrc,buildform
  // body of buildform here
  ...
   return;
 p                 e

The first time the /copy is processed, it inserts the prototype - this is what you'd want for all your consumer programs. As part of processing, it defines buildform_proto. In your service program, you'd then put a second /copy. Because buildform_proto is defined, the compiler inserts the P...B and D...PI specs. You'd have to supply the procedure body and the P...E spec.

Thank you very much for this answer. Am I correct in thinking that having multiple prototypes in the copy book would require nested ifs so you only get the PI you are after in each procedure? — Sarah Kemp, Feb 20 '14 at 16:21
Nice solution. I think I'll adapt that to TR7's new free-form syntax. B-) — WarrenT, Feb 20 '14 at 18:45
@SarahKemp, no nested ifs needed. But you'd need one if-else-endif for each procedure. That being said, I prefer copy and pasting and changing PR to PI. One reason is that you sometimes you can end up with the same include copied in multiple times. Think utility stuff used in multiple places. To avoid that, I use an /if defined /EOF at the top of each include. — Charles, Feb 21 '14 at 14:22

Charles · Answer 2 · 2014-02-21T15:12:53.877

IMHO, this is one of those things that seems useful, but serves no real purpose and in fact could lead to other problems.

It only saves you from having to copy & paste the parm list. But it's actually more keystrokes. I'm a big fan of "Don't repeat yourself", but I don't see this as duplication but redundancy that increases error trapping. The compiler will let you know if there's a mismatch between PI and PR.

As I mention in my comment on Bucks post, you can run into problem with this. Assuming your include source has not just prototypes type other useful definitions, it's likely at some point you'll find an include file being included from multiple places. The fix for that is to simply have at the top of each include

/if defined(MYPROTO_INC)
/EOF
/endif
/define MYPROTO_INC

Now no matter how many times it's pulled in the compiler will only see the definitions once.

Given that the compile will fail if it sees the same definitions multiple times, I think it's a good idea to not intentionally include the same source. Even if by playing games we can technically not include the same symbol definitions.

Additionally, consider templating your parms..

 d formType_t      S             10a   template
 d formMode_t      s              4a   template

 D buildForm       PR
 D  type                               CONST like(formType_t)
 D  mode                               CONST like(formMode_t)

 P buildForm       B
 D buildForm       PI
 D  type                               CONST like(formType_t)
 D  mode                               CONST like(formMode_t)

This allows callers to easily create a variable to use to pass to your procedure.

You might end up with the templates in a whole other include, for example STDTYPES or APPTYPES.

templates are a great thing to have. It allows for a more robust definition and a single point of change (field expansion anyone?). — jgriffin, Mar 07 '14 at 17:01

WarrenT · Answer 3 · 2014-02-20T18:29:06.680

1

Many shops solve this by putting the parms in a copy book. The copy book is then used immediately after the Prototype (PR) D-spec line, and the Procedure Interface (PI) line.

edited Feb 20 '14 at 18:29

answered Feb 20 '14 at 05:45

WarrenT

4,502
19
27

Is that copy book then inserted into the procedure interface then? I already have the prototype in a copy book... – Sarah Kemp Feb 20 '14 at 15:56
1

My preference is to have the parms in their own copybook. You can nest a /COPY or /INCLUDE in your prototype copybook if you like. I want my prototype parms to always match those in the interface, especially if the interface changes. I'm less worried that every program uses the same prototype name. – WarrenT Feb 20 '14 at 18:35
However, I think I may adopt Buck's solution :o) – WarrenT Feb 20 '14 at 18:42
@WarrenT, if the PI doesn't match the prototype...the compiler will let you know. – Charles Feb 21 '14 at 14:27
@Charles of course. But I want the source to match automatically, with no risk of that compiler error, while only specifying it in one place. The more we can follow the DRY principle, the better. – WarrenT Feb 21 '14 at 23:17

Share definitions between Prototype and Procedure Interface

3 Answers3