Prototype and interface in RPGLE programs/procedures

Question

Reading IBM documentation I become a little bit confused about how to correctly write a program/procedure entry point.

Especially reading this https://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/c092508410.htm
I see:

The prototype with the matching name must precede the procedure interface in the source

And here http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzasd/freeinterface.htm
I read:

If you do not specify a prototype for a cycle-main procedure, you use *N as the name for the procedure interface

So I code a new program this way:

CTL-OPT ...

DCL-PI *N;
  P1 CHAR(2);
  P2 CHAR(2) CONST;
  P3 CHAR(2) CONST;
  P4 CHAR(1) CONST;
  P5 PACKED(7) CONST;
  P6 POINTER;
  P7 INT(5);
END-PI;

...

and it compile and run fine.
So what I'm asking is, when and why should I specify a prototype before the interface?

As @jmarkmurphy says, it's probably a good idea always to create a prototype (and keep it in separate source). For at least the lifetime of the next couple of compiler releases, it can be worthwhile to keep the practice active. But in short, if the prototype will never be used in some external RPG IV module, then it doesn't strictly need to be created (in i 7.1 or later). — user2338816, Dec 15 '16 at 12:37

jmarkmurphy · Accepted Answer · 2016-12-15T12:29:52.997

3

The short answer to your question is always create a prototype for an RPG4 program. It may be optional, but you might need it down the road.

I have begun using linear main procedures for programs rather than cycle main. You do this by including ctl-opt Main(procname) at the head of the program. I also put my prototypes in separate source files. That way I can easily include them with /copy directives which has a side effect of collecting external program and service program dependencies near the top of my programs. I prefer to put all prototypes in a separate source file, named the same as the program source. Or for service programs, I name it the same as the service program. But some places I have worked will put a suffix at the end of the prototype and store it in the same service program with the program or module source. The nice thing at v7.1 is that you don't have to define prototypes for internal procedures, just the ones that are exported. At the program level, that is the main procedure, and while that is strictly not required, I always create that prototype in it's own source, because you never really know if you are going to want to call that program from somewhere else at some time in the future. Also while it is not required for you to include the prototype in the program itself, doing so is a good way to verify that the prototype is valid.

edited Dec 15 '16 at 12:29

answered Dec 15 '16 at 12:09

jmarkmurphy

11,030
31
59

Thanks for the info! Why do you prefer linear over cycle? Is it because you can pass parameters by value? It's interesting! – LppEdd Dec 15 '16 at 13:10
1

No, I don't think you can pass parameters by value to the main procedure, I think you have to use a constant reference to replicate that. but what is the sense of including the cycle in a program that isn't going to use it? That means you have to open and close files yourself, and do all the housekeeping for yourself (*INLR has no effect). But everything is defined as a procedure, and you can keep most everything in local scope if you wish. The `ctl-opt Main()` keyword tells the compiler which procedure is the main procedure. – jmarkmurphy Dec 15 '16 at 13:28
1

I meant that you can pass by value in subprocedures ; ) For files open/close, I usually just dont' use USROPN, and they close correctly. For *INLR, it works good! – LppEdd Dec 15 '16 at 16:30
In both linear and cycle main programs the sub-procedures can pass parameters by value, and main procedures can't. In cycle main programs the cycle takes care of opening and closing files. *InLR is an artifact of the cycle as well as primary and secondary files, matching record logic, level indicators, etc. These things do not function in linear modules. Thus I said you have to open and close your files, and *INLR won't work as expected. – jmarkmurphy Dec 15 '16 at 17:47

score 2 · Answer 2 · answered Dec 15 '16 at 09:37

So, going in details and looking at the changes in 7.1 > (for full free form syntax) I found this:
What's New in 7.1?

If a program or procedure is not called by another RPG module, it is optional to specify the prototype. The prototype may be omitted for the following types of programs and procedures: A program that is only intended to be used as an exit program or as the command-processing program for a command A program that is only intended to be called from a different programming language A procedure that is not exported from the module A procedure that is exported from the module but only intended to be called from a different programming language.

It's worth having a good read of all the "What's new" pages!

score 2 · Answer 3 · answered Dec 16 '16 at 18:33

About having to manually open and closE files ...

Files are automatically opened for all files defined in RPG modules, unless the USROPN keyword is specified. This applies to global files in any type of module, and for local files in a subprocedure.

What does differ is when or if the file is automatically closed, depending on where the file is declared. Static files in subprocedures or global files in NOMAIN or linear main modules are never automatically closed until the activation group ends. Automatic files in subprocedures get closed when the subprocedure ends, and global files in cycle main modules get closed according to the RPG cycle.

Hi Barbara! Thanks for your answer! Since I know you develop the RPG compiler, I need to ask you another question. Why embedded SQL with LIKEREC defined DS do not work? I mean, the program compile, but results are unexpected everytime (for SELECT clauses with DS fields in WHERE) — LppEdd, Dec 17 '16 at 12:25

Prototype and interface in RPGLE programs/procedures

3 Answers3