The registration process is contained in copybooks and is the same as it has been for years now. The tame program uses these same constructs. The only real difference is that the condition handler is a *SRVPGM rather than a *PGM
This is our call to register/deregister:
BEGSR RegHndlr;
CEEHDLR(pConHdlr : %ADDR(CommArea) : *OMIT);
ENDSR;
BEGSR DeRegHndlr;
CEEHDLU(pConHdlr : *OMIT);
ENDSR;
Steve Needles
-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Friday, May 13, 2016 4:29 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: %ADDR() in a DS is not resolving to the correct value.
On 13-May-2016 15:31 -0500, Needles,Stephen J wrote:
<<SNIP>>
In the failing program, using the DS's %ADDR() the pointer has a
value, but it won't pass to the condition handler.
I infer that implies the INZ(%ADDR(PGM_PSDS)) is verified to have effected a value for the DS pointer *other than* null.
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.
<<SNIP>>
Is the CEEHDLR being invoked properly; i.e. argument of *OMIT [or *NULL pointer] versus omitting the /omissible/ parameter? That info was not part of the OP.
The differences between a test-program and another program that a test-program mimics could see one succeed without errors whilst the other bombs; even if both are coded with the /same/ incorrect invocation, because the effects are /unpredictable/ per GIGO. See:
[
http://www-01.ibm.com/support/docview.wss?uid=nas8N1019244
Clarification on Why Message MCH3601 or MCH0601 is Received in an Application Reference #:N1019244 Historical Number: 326127886 "... Another common mistake deals with the use of API parameters that are documented as "omissible". These are not optional parameters.
"Omissible" means that it is valid to pass a null pointer instead of a parameter. Your programming language may allow you to pass *OMIT as a parameter in this case. If you neglect to pass an omissible parameter, the API may refer to the location where the parameter should have been, and it may find a valid pointer from some earlier call which may be completely unrelated to your application. If the API then updates that parameter, it will cause storage corruption in whatever storage that pointer happens to be pointing to. The most common error is failing to pass the "feedback" parameter to CEE APIs. A symptom of this error is that storage will be corrupted with a value beginning with "CEE".
..."]
--
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
