Hi, Jon:
I think that somehow you may be confusing the MI concepts of "invocation
pointer", "procedure pointer" and "system pointer".
An "invocation pointer" is used to represent an active invocation of a
program or service program procedure; it points to a data structure that
contains _both_ the address in the code (of the instruction to return
to) and a pointer to its "environment" (the local storage allocated for
that procedure), in order for the system to be able to restore the
correct "runtime environment" (runtime stack) and continue the execution
correctly.
When you issue the RSLVSP instruction to resolve a pointer to either a
*PGM or a *SRVPGM, you get a "system pointer" -- this is a pointer to an
MI object in single-level storage -- there is no associated "activation"
or allocated storage, at that point.
However, to resolve the address of a procedure entry point in a *SRVPGM
into a "procedure pointer" requires that the service program must first
be _activated_. This activation process allocates any storage for this
activation, within some activation group, depending on how the *SRVPGM
was "linked" or bound -- created as ACTGRP(*NEW, named or *CALLER). So,
I believe procedure pointers actually point to a data structure that
contains _both_ the entry point address (of the code) and its
environment (activation).
Most of this happens "automagically" (by the OS dynamic loader) "under
the covers" when an ILE *PGM refers to one or more *SRVPGMs, unless the
*SRVPGM was bound with the (new as of V6R1) *DEFER) option, when the
calling *PGM is first activated. If the *DEFER option was specified,
then the OS "plugs in" the address of a dynamic loader "stub" routine
that handles activating the "real" *SRVPGM, if and when any of its
procedures actually get called, and the address of each stub then gets
replaced with the address of the real procedure(s) in that *SRVPGM, so
that all subsequent calls can run at full-speed/./
For more details, see also the documentation of the following APIs:
QleActBndPgm
QleGetExp
Does that help?
All the best,
Mark S. Waterbury
> On 1/13/2012 1:38 PM, Jon Paris wrote:
On Jan 13, 2012, at 1:00 PM, rpg400-l-request@xxxxxxxxxxxx wrote:
Jon, this scenario doesn't cause an error. (I didn't think it should,
but I tried it just in case.) It looks like the resolved system pointer
to the program is not related to the called program's activation group.
That's interesting ... I always believed that the invocation was tied to the AG.
I wonder how it does work then? I can't see how/why the situation is any different to the Service Program scenario. The SrvPgm problem arrises because there's nothing to tell the caller that it needs to reinitialize the proc ptrs because the original copy has gone away. So what causes the OPM program to re-resolve the pgm pointer? If it doesn't need to re-resolve then why is there a problem with srvpgms? It just seems that if it breaks in one scenario it should break in both.
Jon Paris
www.partner400.com
www.SystemiDeveloper.com
midrange.com
