× 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.



Yes, Buck. In regard to performance I was thinking *NEW vs. *CALLER. And I
agree that NAMED could address the performance concern. As you surmised,
*CALLER is required because of a design that entails the sharing other
resources between the NEP and the service programs that are dynamically
activated at runtime.


On Tue, May 9, 2017 at 11:59 AM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On 5/9/2017 12:27 PM, Nathan Andelin wrote:
In the testing I've done so far, the service programs were created using
*caller activation group and alwrinz(*no), which are defaults for the
create command. The *caller activation group is essential in this case,
for
performance reasons.

I assume you're writing of the difference between *NEW and *CALLER.
There is a third option: a named activation group. With respect only to
performance, such a design would result in one more activation in the
job, and thus would be slightly slower - once. After the initial
activation, the subsequent sub-procedure invocations would not require
activation.

With respect only to 'cleaning up' having the service programs in a
named activation group means that the clean up code knows which
activation group to reclaim.

With respect to architecture, *CALLER is intended to share memory,
overrides, and open access paths between programs and sub-procedures in
that activation group. If your situation is such that a separate
activation group (and thus separate overrides, etc) would break your
application, then clearly a named AG is not going to be a path you can
take.

--

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.