× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.