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".
…"]