I believe that an ESPIE(X) will capture the "compare-and-trap-instruction data 
exception", but a much better solution would be if z/OS supported the efficient 
setting of a TRAP exit routine to get control on a trap condition rather than 
having to generate an interrupt exception.  Unfortunately using the TRAP 
hardware design involves updating the DUCT in protected storage, so not 
possible for normal application code to use.  I believe I remember that Mr. 
Relson has complained publicly on one of these fora at least once that some 
(unidentified) IBM program product implemented their own access to the hardware 
TRAP facility and the DUCT fields without consulting with the z/OS BCP 
maintainers.

He had some reasonable concerns about integrity and recoverability in complex 
z/OS environments when directly using the hardware TRAP facility.  If I 
remember correctly, cleaning up after abends in multi-tasking environments with 
complex recovery routines was a particular concern.

Peter

-----Original Message-----
From: IBM Mainframe Assembler List <[email protected]> On Behalf 
Of Tony Harminc
Sent: Wednesday, September 9, 2020 5:49 PM
To: [email protected]
Subject: Re: Deep Cuts

On Wed, 9 Sep 2020 at 17:30, Charles Mills <[email protected]> wrote:

I think faulting on dereferencing 0 is a hardware function and yes, most
> hardware does so. Not so Z, where traditionally much of the "API" is 
> chained off of the PSA.e unable to reference the PSA via a pointer variable.
>

Newish zArch has  a number of instructions of the form xxx AND TRAP, where xxx 
is COMPARE or LOAD with various modifiers. These fault upon a zero result, but 
lead to a "compare-and-trap-instruction data exception" rather than, say, an 
addressing or protection exception. I don't know if the C compiler can be 
convinced to emit them, and if there is z/OS infrastructure to capture the 
resulting exceptions.

Tony H.

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

Reply via email to