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

["Nadir Amra" <amra@xxxxxxxxxx>]

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