Some time back I started a thread on this forum about writing authorized code or a PC routine to update the DUCT architectural control block to populate the TRAP fields to make active use of the variety of TRAP instructions now provided, and the common consensus at the time was for me to keep my grubby hands off the DUCT lest I cause a catastrophic and possibly ipl-able failure.
IIRC there was a comment in that thread by one of our regular IBM contributors that at least one IBM product had gone ahead and used that technique without dispensation from the core z/OS developers who were (at least at the time) not happy about the choice made by those product developers. We have yet to see any further word from IBM on when or if z/OS will provide the needed system-level interfaces to "safely" use TRAP and friends. "Business justification needed" and "ROI" are of course the usual reasons given for delaying support for the architected hardware capabilities. Hiring more core z/OS developers and testers to keep up with support for all of the hardware capabilities never seems to be on the list of possible solutions. z/Linux may or may not be ahead of z/OS in regard to actually using TRAP and friends, but I don't know where one would look to find out if and/or how it is implemented there. Peter -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of John McKown Sent: Thursday, June 20, 2019 9:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Use of "trap" facility in z/OS? This is purely speculation, but I like what I've read about the "trap" facility. I think it is too bad that z/OS doesn't support the use of TRAP2, TRAP4, as well as the compare-and-trap and load-and-trap. I agree that they are not _necessary_ since the code can do basically the same thing. The only reason that I even bring it up is that the paper "IBM Z / LinuxONE System Processor Optimization Primer" by C. Kevin Shum on page 51 "Optimization - Instruction Selection (1)" recommends using "compare-and-trap" where practical, in particular, for null-pointer checking. Perhaps I should have waited for Friday to post this since it is only wishful thinking. -- 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. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
