Re: Activation group vs Procedure -- MIDRANGE-L

> I thought I would change the browse rpg program into a procedure, since
> procedures are recursive. But then, I came across this in the manual
> QUOTE:
> If you create an ILE RPG program with ACTGRP(*NEW), you can then call the
> program as many times as you want without returning from earlier calls.
With
> each call, there is a new copy of the program. Each new copy will have its
> own data, open its files, etc.. However, you must ensure that there is
some
> way to end the calls to 'itself'; otherwise you will just keep creating
new
> activation groups and the programs will never return.
> ENDQUOTE
>
> So, my question is "Whats the better way to handle this, procedure or new
> activation group?" As a follow-up, if activation group *NEW, then whats
the
> best way to end the calls to itself?
>
> Ron

Procedures offer capabilities that subroutines can't (parameter passing,
prototyping, local variables, etc). You could replace all of your
subroutines with
procedures, though this is really a matter of preference I think. I use the
best
technique for the task at hand. BTW, you can have subroutines within a
procedure.

Activation groups are a separate issue from procedures / subroutines.
If you have a case where PGM1 calls PGM2 which in turn can call PGM1,
then you need recursion. With RPG, using NEW activation groups is your
only choice. Be aware that using *NEW has consequences. Each
activation group that is started has overhead (last I heard this was
somewhere
between the overhead of a dynamic call and starting a new job). Each
instance of a new activation group will incur this overhead. You also could
have problems with things like overrides.

One other point is that you don't have to make it a subprocedure to add it
to a service program. You can take a regular old RPG IV program, compile
it to a module and then use that module in a service program. Now you
would use a CALLB in your calling program to call that program instead of
a CALL. You are not using BIND BY COPY but rather BIND BY REFERENCE
because it actually resides in the service program.

I have a pricing program that was about 800 lines of complicated (and of
course relatively undocumented) code. I converted it to RPG IV and then
placed it in a service program. Parts or all of this logic is used in more
than
60 programs in the system. The COPY AND MODIFY technique was used
to "share" this code. We now have virtually 60 different versions of the
code.
The goal is to replace all of these disparate chunks of logic with a call to
that
service program. We will then have a single place where all of the price
logic
is located.

+---
| 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
+---