Chuck,
The code has been fine on 7.2 for more than a year. 7.2 is not a new issue.
Chuck: So the pointer is *NULL? What does the EVAL of the pointer show in debug?
Steve: In the failing program, using the DS's %ADDR() the pointer has a value, but it won't pass to the condition handler. When the address is specified in the c-spec, the address makes it to the condition handler. So in debug with the DS version, the pointer is valid in the failing program and invalid in the condition handler.
Chuck: Invalid how? Is the failure a MCH3601 error for _reference_ to a null pointer? Or is there some other pointer error diagnosed?
Steve: When the condition handler program accesses a field within the addressed PSDS, the variable is un-addressable. I'll get better data on this on Monday.
Chuck: 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?
Steve: Yup. But the whole idea of putting it into the DS was to eliminate the need for the developer to be mindful of the handler. All they need to know is to plug the copybooks into the correct place and all is well. My issue is that it works with the tame test program and not with the other.
Chuck: 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?
Steve: Yes. But the tame program uses all of the same constructs as the one that fails...the exact same copybooks to define prototype, variable, sub-procedures and subroutines. These are all proven components. The only thing the tame program has going for it is that it will always fail, by design, thus invoking the handler.
I hope this answers your questions Chuck. Thanks for weighing in!
BTW - I have submitted a PMR on the issue.
Steve Needles
-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Friday, May 13, 2016 2:58 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: 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.
--
Regards, Chuck
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
________________________________
This communication, including attachments, is confidential, may be subject to legal privileges, and is intended for the sole use of the addressee. Any use, duplication, disclosure or dissemination of this communication, other than by the addressee, is prohibited. If you have received this communication in error, please notify the sender immediately and delete or destroy this communication and all copies.
TRVDiscDefault::1201
midrange.com
