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

On May 10, 2017, at 8:12 AM, Mark S Waterbury <mark.s.waterbury@xxxxxxxxxxxxx> wrote:

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.

--

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: http://amzn.to/2dEadiD