FWIW,
some years ago (maybe 2010), I replaced the breakpoint mechanism in a
home grown debug tool
written by my customer; the breakpoints were implemented by capturing
the S0C1 interrupts of hex zero
insertions into the load module instead of real opcodes. I now insert
TRAP2 instead of hex zero.
So: I know how to do this ... maybe others on this list, too. The
problem is: to insert the address of the
TRAP handler routine into the DUCT, you need to be authorized. In our
installation, we created something
like a special "user SVC" to do this (don't know the details, because
this was done by our systems people).
That is: a special SVC which only allows to "configure the DUCT". I
wrote the specification, and then the
systems people created the SVC.
All other actions can be done by normal non-authorized code ... this is
kind of easy. The rest of the debug tool
remained unchanged. The debug tool was much faster after this change,
because the RTM work involved
by the S0C1 handling is now saved.
This is a very special application, of course, and I never would have
thought about using TRAP2, if the
debug tool of the customer didn't exist already (since the 1980s, long
before TRAP2 arrived, which was ca. 2000,
IIRC). But when I learned about the internals of the debug tool (the
S0C1 mechanism), it seemed
sort of natural to me to think about this TRAP2 replacement. And the
customer allowed me to give it a try.
If you want to know more, feel free to ask me offline; maybe I remember
the details after all this time.
The debug tool is still in daily use by the developers at the customer's
site (for PL/1 and ASSEMBLER programs).
Kind regards
Bernd
Am 01.03.2023 um 17:32 schrieb Farley, Peter:
<*Sigh*> Yes, I do understand the "business justification/resource allocation"
argument/excuse. I deal with similar issues all the time in my employer's business. I hate
it, but it is real.
IMHO the IBM z/OS development team should never have *needed* a "formal
request/requirement" to implement OS support for an implemented architectural
feature. There is a new hardware feature, our clients will no doubt wish to take
advantage of its benefits, let's support that feature. Full stop.
But please accept my apologies, I am obviously beating that poor dead horse
once again.
As an alternative, would it ever be possible for IBM to publish the program design and
detailed error-handling needed to practically and *safely* use the TRAP feature? Maybe a
Redbook project sponsored by the Debug Tool team? Something detailed enough to enable a
knowledgeable independent developer to produce the code you say IBM won't ever write. I
wouldn't expect the major ISV's to undertake it, it is far too small a market for them to
spend real money on (there is that dad-blasted "business justification" thing
again), but an independent developer might wish to spend *their* private time on getting
it done, IFF they had all the details needed to do it the right way without needing to
guess what to do.
I would hope that publishing information on how to properly and safely use an
existing (and already published) architectural feature wouldn't run afoul of IP
concerns.
Peter
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
Peter Relson
Sent: Wednesday, March 1, 2023 9:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 3.1 Announcement US Letter
EXTERNAL EMAIL
Peter F wrote:
<snip>
What I would like to know is when z/OS development will finally manage to find
the round tuits to actually implement a supported API to actually be able to
USE the TRAP (and compare-and-trap) instructions introduced to the architecture
so long ago I have forgotten which zArch generation they in came with (and I'm
too tired to go looking for that generation today).
</snip>
I believe IBM Debug Tool uses this. But you're right that there is no API
provided.
And given the amount of time that has gone by and the fact that, to my knowledge, there
never has been a formal request/requirement submitted asking for such an API, the answer
to your question (unless such a requirement is submitted) is, in practice,
"never".
And a new requirement might be declined unless there is significant business
justification that would make this a good candidate.
We all wish that we were in a world where "should" would match "it is", but there is always a
resource tradeoff to be made between competing items and the question has to be answered of what would you the customer
(and IBM) be willing to sacrifice getting in order to get "this". "Should" only takes you so far.
That should be apparent to all (but many discussions on IBM-Main do not seem to take that into account).
Peter Relson
z/OS Core Technology Design
--
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
