Re: A question about multi-module SRVPGM

Hi, Tom:

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

Note also that OS/400 and i5/OS have a capability known as "shared" activation groups, but as far as I know, IBM reserves the use of this feature for IBM internal use only.

There are also a number of components of OS/400 or i5/OS that exist in the form of *SRVPGMs that are activated in the "system activation group", which is system-wide, and thus is "shared" across all jobs. IBM provides no way for users or customers to create programs that can run in this "system activation group".

Hope that helps.

All the best,

Mark S. Waterbury

> Tom Liotta wrote:

Mark S. Waterbury wrote:

Consider this scenario:

service program A references (invokes procedures within) service programs B and C

[snip many references]

service program G references service programs W, X, Y and Z

As soon as service program A is activated (because the first ILE *PGM that references it was CALLed (activated), the following occurs:

A is activated

[snip many activations]

Z is activated
H is activated

[snip]

Does this "make sense"?

It makes sense, but seems to leave a potentially important element unexplored.

At the end of the activation sequence above, we find Z & H being activated because A was activated at the top and the reference chain got started.

However, what if Z & H were already activated by a different job?

That is, if service programs are comprised of modules that are used _in common_ by various programs in various jobs, how many activations are likely? You showed examples of E & F previously activated higher in the reference chain in the same job, but how about multiple jobs?

Compare a nightly dedicated batch subsystem with a single-threaded job queue to multiple server jobs with some number of reuses. The batch processing might fully resolve a reference chain for every new job. The multiple server jobs might only rarely activate a new service program. No?

...unless I misunderstand it entirely.

How much does it matter under varying circumstances? How can anyone determine if it's significant at all?

So, yes, it makes sense. But does it matter?

Tom Liotta

> David FOXWELL wrote:

I'm starting to hesitate before posting my question.

When you say only one copy of the service program code will be loaded into memory, would that mean the whole code for all the functions it may have, even if the calling program only used on of those functions?