RE: Procedures

>>Do I make it a service program?
>
>If you only use a procedure in one program, then 
>no. If you will use it in many places then yes.

That's IBM's answer, straight from the manual.  It's a good one, and here's
why:
A procedure is a function - it does one thing only, like
GetDayOfWeek(yyyymmdd)
A module can be thought of as a collection of common procedures - like
putting all the date handling procedures in DATMOD.
A program can be thought of as a collection of modules connected by your
mainline code.

If you bind your modules directly to the base program, you are using "bind
by copy."
If you bind your modules into a service program (which in turn gets bound to
your base program) you are using "bind by reference."
The difference is that if you bind by copy, you literally make a copy of the
object code in your base program.  If you bind by reference, you are
referring to one copy of the object code.  Clearly, if you want to use the
date handling functions (contained in DATMOD) in many programs, it would be
an advantage to create a service program out of DATMOD and bind to that.  

Let's assume that you have GetDayOfWeek created in module DATMOD.  You've
put the prototype to GetDayOfWeek in a separate source member called
GETDOWPR.  You add the /COPY GETDOWPR line to your 10 programs that need
this function, you add the DayName=GetDayOfWeek(InvoiceDate) and you
CRTRPGMOD on your base programs.  Then you CRTPGM on all 10, specifying
MODULE(basename DATMOD).  This is bind by copy.  All 10 programs have a copy
of all the functions contained in DATMOD.

If you find a bug in GetDayOfWeek, you'll have to edit, CRTMOD DATMOD, find
all the programs that use DATMOD and UPDPGM them to use the new DATMOD code
(containing the repaired GetDayOfWeek procedure.)  Bummer.  Don't miss one,
because it'll have the old (broken) copy of the procedure!

If you create a service program out of DATMOD, then you create the 10 base
programs with BNDSRVPGM(DATSRV), you avoid this hassle.  The base program
waits until run time to go find the DATSRV service program, perform the
bindings and locate the procedures inside the service program.  

My advice is somewhat modified from IBM's.  I would say that if you truly
have a procedure that will only be used in one program that you don't need
to worry about modules at all - just inline the whole thing, PR and PI, then
do a CRTBNDRPG.  When you need that procedure for the second program, it'll
be easy enough to extract and put into a service program because your
procedure will only use local variables (right?) and have everything
"external" to it passed in via the parameter list.

>Again, there has been much written about procedures 
>in the trade magazines. There are several people 
>who give seminars on RPG/ILE. COMMON is another 
>good way to learn.

I agree completely...  Get as many opinions as you can.  People do things
different ways; get them to explain WHY they prefer a particular method and
you'll get a pretty good understanding of what will work best in your
environment.  Like you, I'm at the starting point for this stuff, and it's
been something of an interesting road if only because of the jargon.

Buck Calabro
Billing Concepts Albany, NY
mailto:mcalabro@commsoft.net


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---