Re: A question about multi-module SRVPGM

Mark S. Waterbury wrote:

Normal activation groups exist "per job" or exist within a job, so there is no "sharing" between jobs. Note however that the executable code (the pages containing the actual RISC instructions) are "shared" in the vast single-level storage address space, and because the compilers always generate reentrant code, these pages are "read-only" and cannot be modified, and so they can be shared. But the "activation" is really about the allocation of any static storage for a *PGM or *SRVPGM, and this is dynamic storage that exists within the temporary storage of a given job, and within some activation group within the job (either the *DFTACTGRP or some other ILE activation group).

Hi, Mark.

Okay, so now the scope is better defined in this thread. And that brings us to this earlier element: "F is already activated, so just resolve pointers within service program C that point to procedures within F".

Now, CRTSRVPGM allows two values for ACTGRP() -- Name or *CALLER.

That would seem to be an interesting area for service programs when the *CALLER runs in *NEW.

I've used a named ActGrp for a service program that acts as a storage container for values that I want to retrieve later in a job. Handy.

I haven't referenced my own service programs from a *CALLER in a *NEW ActGrp. That hasn't been needed yet by me. That would seem to be a tricky performance issue if *NEW wasn't used carefully, most especially if the earlier mentioned service program reference chain was complex. (Nor have I referenced them from an ActGrp that is reclaimed very often.)

So, it goes back to the *PGM that actually references the service program. ...At least, the *PGM in a given ActGrp. When a job has multiple ActGrps and the service program runs in *CALLER, the reference chain may cause multiple activations of the service programs in the chain -- one for each different calling ActGrp and even for each reactivation of such ActGrps.

But if the *PGM that binds the *SRVPGM isn't called, then no *SRVPGM activation happens at all. That CALL might be in an IF-statement and never triggered.

And that all leads me to consideration of creating service programs to have a named ActGrp of their own, perhaps groups of *SRVPGMs in a few ActGrps. I.e., blind reliance on *CALLER for *SRVPGMs should be reviewed if performance will be an issue.

Hope that helps.

Maybe; we'll see. I mean, your discussion is excellent -- my comprehension is the obstacle in this area. My daily experience with activations is kept within a pretty strict scope since we're not exactly involved with general business apps. Our activation structure was fairly well settled a number of years ago and there've been very few reasons to make changes.

As it happens, though, there is a particularly nasty issue that needs resolution involving hundreds of millions of calls to an API. So, I'm getting ready to learn more than I ever wanted to know.

Tom Liotta