RE: Starting out with sub-procedures -- RPG400-L

On Mon, 2003-10-27 at 19:41, Scott Klement wrote:
> > > What is a Procedure?
> > A re-usable piece of code, frequently in a *MODULE object, that performs
> > a specific function and may or may not return a value.
> 
> I don't understand what you're trying to say here when you say "frequently
> in a *MODULE object."   Everything is in a *MODULE object...

Sorry, I was in a real hurry when I wrote this response.  I was thinking
specifically of procedures as BIFs, specifically in a "1 procedure per
module" approach.  Yes, everything is a procedure and at one point in
the lifecycle everything is in a *MODULE. It's good to note, though,
that they are unusable in the raw *MODULE form: you must either bind the
module to a PGM object or a SRVPGM object, and once done the *MODULE
object can be eliminated.  This is good to know if you ever end up
distributing objects.

> A procedure is, basically, callable code.   There are two types of
> procedures:  "Main procedure" and "Sub-procedures."
> 
> The main procedure is the one with the *ENTRY PLIST.   If you've never
> coded a subprocedure, then all of your code has been in a main procedure.
> The main procedure is the one called automatically as part of the RPG
> cycle.

In my head I've always differentiated this by PROGRAMs (procedures with
*ENTRY or PI) and PROCEDUREs (those with no entry).  I know it's not
really correct, it's just the way I resolved the basics in my brain a
long time ago and every once in a while it slips out.  Please don't hate
me.

> Each module can have a separate main procedure.  If your program is made
> up of many modules, you have to designate one main procedure as the
> "entry procedure" to designate that this is the one that will be called
> automatically when your program is activated by the CALL op-code.
> 
> 
> > > What is a sub-procedure?
> > Simplistically the same as a procedure.  Specifically it has no cycle,
> > as defined by "nomain" in the H-Specs.

Again, from the seperate modules viewpoint, sub-procedures is a term
typically used to mean a BIF-like entity with "nomain".  Is this all
encompassing?  Of course not, as Scott has pointed out.

> You can have subprocedures and "NOMAIN" without any conflict.   NOMAIN
> means that you won't have a main procedure.  You can have both a main
> procedure and subprocedures both in the same module without any problems.

Do you mean sub-procedures and the <i>lack</i> of "nomain"? Can you have
a MAIN procedure with "nomain"?  I don't think so... the cycle must
exist for an *ENTRY point, mustn't it?

I was trying to say that most stand-alone sub-procedures are defined
with "nomain", so obviously I don't think there is a conflict.  But for
the record, yes you can have a ton of sub-procedures in an object NOT
defined with "nomain".

> A subprocedure is a "sub-program" or "function."  It's like a subroutine,
> except that variables can be "scoped" so that they only exist in the
> subprocedure.  It greatly improves testing & reusability if all variables
> in a subprocedure only exist in that subprocedure.  You don't have to
> worry about your main proc or other subprocs affecting the values of your
> variables, therefore you don't have to re-rest each subprocedure when a
> small change is made.   You can re-use the subprocedures in each program,
> because unlike subroutines, you don't have to have particular global
> variables set up in a specific way to use the subprocedure.

Absolutely.