× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Activation group vs Procedure
  • From: Alan Campin <Alan.Campin@xxxxxxxxxxxxx>
  • Date: Sat, 20 Nov 1999 16:55:12 -0700

>> Converting to sub-procedures is probably a lot 
>> of work, *NEW may be a good starting point/compromise.

Only if you are not calling a program recursively a lot of times. Activation
groups are absolute killers. They take a huge hit on resource. They are
roughly equivilant to a new job. Better but still big hitters. So don't
create a function in a program and then call it in a loop for 50 times
unless you want to watch your AS/400 grind to a stop. I made that mistake
once. Geez, what happened to the whole system?


-----Original Message-----
From: David Morris [mailto:dmorris@plumcreek.com]
Sent: Saturday, November 20, 1999 4:05 PM
To: MIDRANGE-L@midrange.com
Subject: Re: Activation group vs Procedure


Ron,

I agree that maintaining n copies of a program to support recursive calls 
is a little convoluted.  Using *NEW in this case makes a lot more sense.  If

you decide to change your routines to sub-procedures, you will need to 
do quite a bit more evaluation of your programs.  Any global values will 
have to be localized.  Opens will also be shared which may require some 
restructuring of your applications.  Your may also want to spend some time 
identifying the common parts of these programs and supporting them in 
separate, shared routines.  Converting to sub-procedures is probably a lot 
of work, *NEW may be a good starting point/compromise.

David Morris

>>> HwaRangRon@aol.com 11/20/99 09:28AM >>>
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
+---
+---
| 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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.