Re: Is there an API to "deactivate" an "active" service program?

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.

--