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

It should be pointed out that not all resources are tied to activation
groups. For example, if using the UNIX APIs to access IFS files, the
descriptors to opened files are tied to the job, not the activation group.



"MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx> wrote on 05/10/2017
07:12:43 AM:

From: Mark S Waterbury <mark.s.waterbury@xxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 05/10/2017 07:13 AM
Subject: Re: Is there an API to "deactivate" an "active" service

program?

Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>

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.

--