Re: Activation group vs Procedure

[Larry Bolhuis <lbolhui@xxxxxxx>]

We solved this problem by coding the programs to not call each other directly 
but
rather pass all 'calls' through a single program.  The parameter list for each
program was standardized and included one large parm mapped to a Data 
Structure. 
This allowed 'recursion' because the program only evey actually got called one
time and always from the main program. The programs available to be called were
stored in a file.  In each program we defined a multi-occurance DS with 5
occurances and we switched forward to a new one on a 'call' and backward on a
'return'. We kept a stack of active programs in the main program and used F12 to
walk back down the stack.  This setup had the side benefit of a) Nearly zero
overhead for each additional call (just the DS swap) b) Because the callable
programs were in a file we could add them/remove them at will. c) Because all
calls went through one point we could easily track the number of calls made ('is
this program used much?') d) we could secure the calls easily all in the main
program.

By the way we set all that up to run in a single group job so that it stayed
active all day.  The users could jump in and out at will. (They used ATTN to get
in and F3 or ATTN to get out.)

 - Larry

HwaRangRon@aol.com wrote:
> 
> Reading the manuals seem to raise more questions than they answer.
> 
> We currently have a program that presents a browse window over any of 50
> files. Each file is user controlled open, controlled by a code passed to the
> program. Once the subfile is presented, the user can optionaly enter a
> request to go directly to the maintenance program for that file. Once in a
> maintenance program, the potential exists for the user to request the browse
> window again and cause a recursion error. Currently to handle this, we call
> the browse window program from a CL program that monitors for the recursion
> error message and calls a clone of the browse window rpg program if
> necessary. We know from analyzing our software, that you can never get more
> than 3 deep, so we have 3 clones of the program. This works, but it is very
> messy!
> 
> 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
> 
> 
> +---
> | 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
> +---

-- 
Larry Bolhuis         | What do You want to Reload today?
Arbor Solutions, Inc  | Don't throw your PC out the window,
(616) 451-2500        |  throw WINDOWS out of your PC.
(616) 451-2571 -fax   | Two rules to success in life:
lbolhui@ibm.net       | 1. Never tell people everything you know.
+---
| 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
+---