Re: Prototypes

[Justin Houchin <jhouchin9@xxxxxxxxxxx>]

Thanks Joel,

    I understand it ALOT better than before!!!!

Justin Houchin
Programmer
Reliatek, Inc

----- Original Message -----
From: "Joel R. Cochran" <jrc@masi-brac.com>
To: <rpg400-l@midrange.com>
Sent: Wednesday, April 17, 2002 11:10 AM
Subject: RE: Prototypes


> > -----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
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
>