Re: %ADDR() in a DS is not resolving to the correct value.

On 13-May-2016 12:34 -0500, Needles,Stephen J wrote:

OS version is 7.2.

I've a program that uses a registered condition handler that is a
*SRVPGM.

There is a copybook that contains the data structures, prototypes
and other variables that define the interaction between the failing
program and the condition handler using IBM's CEEHDLR API.

Among the DS's is the PSDS and the Communication Area used for the
condition handler. This was all developed according to IBM's
examples many years ago.

For reference\example, for anyone curious:
IBM i 7.1->Programming->Programming languages->RPG->ILE RPG Programmer's Guide->Debugging and Exception Handling->Handling Exceptions->ILE Condition Handlers->Using a condition handler
[http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/rzasc/sc092507346.htm%23hcndhd]

If this is code that has always functioned correctly, and is only failing now, since v7r2, best might be to report the issue to a service provider [likely for most, to IBM].

The Communication Areas DS contains a pointer to the failing
program's PSDS. It is defined as follows:

* Communication area *
*---------------------------------------------------------------
D CommArea DS NOOPT
D CA_pPsds * INZ(%ADDR(PGM_PSDS))

The DS to pass control to the registered handler includes the above
DS:

* CEEHDLR Interface *
*------------------------------------------------------
D CEEHDLR PR
D pConHdlr * PROCPTR
D CommArea * CONST
D Feedback 12A OPTIONS(*OMIT)

The problems are that when the program is initialized, the pointer
is supposed to have a value, it does not.

So the pointer is *NULL? What does the EVAL of the pointer show in debug?

When the %addr() is obtained in the c-specs, it finds the correct
address for the PSDS.

eval CA_pPsds = %ADDR(PGM_PSDS);

The impact is that as the condition handler accepts control from the
failing program, the address is invalid and the condition handler
cannot resolve the address, so it fails.

Invalid how? Is the failure a MCH3601 error for _reference_ to a null pointer? Or is there some other pointer error diagnosed?

FWiW, for clarity: To _resolve to_ is the action of assigning the pointer-variable to the address of a resource, contrasted with an attempt to _refer to_ an already-resolved resource; the resolve locates the resource [typically by some name; in this case a DS-variable name], obtains the address of that resource, and then that address is stored in\as a pointer variable.

When the address is forced in the c-spec, all works as expected.

Presumably the noted run-time assignment is the circumvention already implemented [the best kind of circumvention; one that never need be undone], pending resolution to the use of the INZ?

I don't think that the *SRVPGM angle has anything to do with the
error as my tame test program works just fine.

Does "tame test program" mean one that is simplified\bare-bones; contrasted with a production[-like] program with all the other sources? If so, does the "tame" program also use the same or similarly-modeled set of includes\copybooks to increase the level of mimicry?

Anyone got any ideas? Barbara? :)

I likely never would see any issue like that, as I typically would have assigned the address to the pointer in run-time, just before invoking the registration of the handler with the Register a User-Written Condition Handler (CEEHDLR) API [http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/apis/CEEHDLR.htm].

Seems possible that the No Optimization (NOOPT) directive might not be accounted for properly by the compiler, per having coded only the initialize vs an assignment; the latter making the /usage/ more conspicuous. Seems from the description, the program may have been functional when compiled at a prior release, so has a Target Release (TGTRLS) compile been attempted to see if that /corrects/ the issue? Of course, if successful, then implying a defect with the way the new compiler generates the initialization phase.