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

Nathan:

Suppose your NEP is set to use a "Named" ACTGRP(NEP), and with all of the *SRVPGMs set to ACTGRP(*CALLER) and run in that AG, and then, when you want to "recycle" your NEP, your application somehow signals the NEP to "end" and it sets LR=ON and returns to its caller -- this could be a small CL program that then issues:

RCLACTGRP ACTGRP(NEP)

This will reclaim all of the resources used by the NEP and any *SRVPGMs that it has activated in that AG during its "lifetime." Then, the CL program can just call the NEP again, to start up a "new" named AG (with the same name), if that is what is desired.

HTH,

Mark S. Waterbury

> On 5/9/2017 2:39 PM, Nathan Andelin wrote:

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.

--