• Subject: Activation group vs Procedure
  • From: Jon.Paris@xxxxxxxxxx
  • Date: Mon, 22 Nov 1999 10:33:28 -0500



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

*New is a perfectly viable option for these circumstances but _does_ impose a
performance penalty. Not only does the new AG have to be created, but also has
to be destroyed when the program that caused it to come into existence returns
to its caller. This is one reason why I don't normally recommend *New. For most
people this is acceptable as the alternative is doing a CRTDUPOBJ each time with
associated clean-up. Since you have a defined 'depth' of nesting it sounds as if
you already have the copies in place and therefore don't hit this problem.

An alternative approach might be to have each of these main line processes run
in their own named AG with the pop-up having the *Caller attribute. This gives
you multiple invocations with the added advantage that the AG hangs around
between calls.

The piece in the manual on the dangers of *New relate to looping indefinitely.
In your case this seems unlikely and as you return from each nesting level it
should take care of itself. There is an API (CEETREK) that you can use to blow
the AG away from within it, by I doubt if you need it.


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


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

This mailing list archive is Copyright 1997-2019 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].