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