RE: Prototypes

["Joel R. Cochran" <jrc@xxxxxxxxxxxxx>]

> -----Original Message-----
> From: Justin Houchin [mailto:jhouchin9@charter.net]
> Sent: Wednesday, April 17, 2002 11:31 AM
> To: RPG Midrange
> Subject: Prototypes
>
>
> This is a multi-part message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> I also have one more question. I am new to procedures. Can
> someone explain in lemans terms  a definition of a prototype,
> procedure, sub procedure and how they relate. I am confused
> on the terminology. I read the section in the back of the
> RPGIV book but I just need to better definition.

I will try to answer your questions, but I cannot adequately do so
briefly...

1:)  Prototypes

The definition of how a procedure or sub-procedure shall be called.  This
sets the rules for the call and must exist in both the calling program and
the receiving procedure in order to use the 'callp' opcode.

Example:
d #OverFile       PR
d  OldFile                      10    value
d  NewFile                      10    value
d  NewLibrary                   10    value
d  NewMember                    10    value options(*nopass)

This states that a call to the procedure '#OverFile' must include the first
three parms and may include the fourth.  Additionally, each is allowed to be
sent by Value instead of by Reference (I'll cover that in a moment).  This
prototype also lets us know that the procedure does NOT return a value since
there is no return type defined to the right of the PR.

To compile the '#OverFile' module, this PR statement must exist in the code.
To call '#OverFile' from another program, this PR statement must exist in
the code.
Because I have used the option 'value' on each of the parameters, I can
issue the callp statement using literals like so:

callp  #overfile( 'myFile' : 'myFile' : 'myLibrary' : 'myMember' )
but I don't have to pass it the fourth parm...
callp  #overfile( 'myFile' : 'myFile' : 'myLibrary' )
because I specified the fourth parm in my PR as *nopass.

If I had not used the values kseyword then I caould only pass variables and
it would look more like so...
eval   myFileName = 'myFile'
eval   myNewFileName = 'myFile'
eval   myLibraryName = 'myLibrary'
eval   myMemberName = 'myMember'
callp  #overfile( myFileName : myNewFileName : myLibraryName : myMemberName
)

It is also good to know that the field names on a PR block are documentary
only and do not exist as variables in your program.  On a PI block, which
must mimc your PR block exactly EXCEPT for the variable names, the names
become program variables.



2:)  Procedure/Sub-procedure

I think there are two acceptable views of a procedure in RPGIV.

First (and the one I typically use) is that a procedure is any 'main' piece
of code.  A parent module if you will.

Second is that a procedure is any piece of code that incorporates the cycle,
meaning it does NOT have NOMAIN at the top of the code.

Tomato tomahta in my view since it is preferred that they are both defined
and called the same way: with Prototypes and Procedural Interfaces (PI
blocks).  Personally I think it is a distinction with little merit.  I tend
to use the term sub-procedure to refer to a homegrown BIF that is meant to
be used as part of an expression or to perform a function but that is just
me.  A procedure to me encompasses the whole entity of a program and what it
accomplishes.


3)  How do they all fit together.

Very nicely :-)

A procedure/sub-procedure has a Prototype.  The same prototype is then used
in the calling program to establish the rules for the compiler.  The
compiler then uses the prototype to ensure that your code is following those
rules when it calls the procedure/sub-procedure.  Since the two prototypes
MUST match exactly, the accepted approach is to use a /copy member to ensure
that the PR is alway correctly defined.


I'm sure this isn't complete but I hope it gets you a little further along.
Al standard disclaimers apply... :-)


Joel R. Cochran
Director of Internet Services
VamaNet.com
(800)480-8810
mailto:webmaster@vamanet.com