Re: Full TRAP feature support
On 3/2/2023 1:04 AM, David Cole wrote: Hi Ed, WRT "ColeSoft acquired zDebug many years ago" I don't recall that we ever did that. We beta tested zDebug (from your old colleague Jeffrey Smith at Farsight Systems) back in 2004 and it was excellent. I remembered it being acquired by Cole not long afterwards. I must have remembered incorrectly. If not Cole, then who acquired that excellent debugger? Is it still around as a different product? z/TDF maybe? -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Full TRAP feature support
I use z/XDC a lot, and I've had SET TRAP2 in my start-up script since I found out about it. It has worked seamlessly for me. The only visible difference is seeing x'01FF' at breakpoints rather than x'00'. And it's great that ZDC and other debuggers figured out how to exploit the facility. I'm still curious about the conditional trap instructions, e.g. LAT, CIT. They have programming notes that imply they're intended for use in try-blocks, or assert. I have no idea if any current compilers use them. sas On Thu, Mar 2, 2023 at 3:06 AM David Cole wrote: > Hi Ed, > > WRT "ColeSoft acquired zDebug many years ago" I > don't recall that we ever did that. > > WRT "and incorporated much of that technology > into z/XDC." I'm sure we never did that. > > z/XDC does have TRAP2 support, but we didn't > implemented it until sometime in 2018. (Peter Morrison did the work.) > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Full TRAP feature support [was: RE: Re: z/OS 3.1 Announcement US Letter]
I agree with most of the sentiments expressed here. But that ship has sailed. And it is far from true that every operating system provides support for every hardware facility. Back when TRAP2 and TRAP4 were introduced (about 25 years ago), OS/390 development (it was pre-z/OS) was not even aware of it. And we were shocked to learn that debug tool had implemented to the architecture. I hope we can agree that that was not appropriate - the OS should have provided an API and debug tool should have used it. Whether that API would have been limited to authorized users is a different question entirely. At this point, nothing is going to be done without a strong business justification. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Full TRAP feature support
Hi Ed, WRT "ColeSoft acquired zDebug many years ago" I don't recall that we ever did that. WRT "and incorporated much of that technology into z/XDC." I'm sure we never did that. z/XDC does have TRAP2 support, but we didn't implemented it until sometime in 2018. (Peter Morrison did the work.) Our TRAP2 support integrates pretty well into our existing X'00'-opcode support. Users can use a simple command (SET TRACE TRAP2|ZERO) TO switch back and forth at will between the two forms of breakpoints. The problem, of course, with TRAP2 support is that the scope of TRAP2 activation is limited to only those tasks (or SRBs) for which a Trap Handler Exit has been linked into the DUCT. But there is no z/OS supported mechanism for automatically installing Trap Handler Exits into a task when one is needed. There are two ways that I can think of to deal with this. One is to place intercepts in z/OS's ATTACH service that adds Trap Handler Exits (when appropriate) at task creation time. (This is NOT what z/XDC does.) The other is to monitor for PIC 0013 (which becomes abend 0D3-13 an ESTAE time) and install the missing Trap Handler Exit at TRAP2 instruction failure time. I don't know what Chuck Arney does, but monitoring for the 0D3-13 is what z/XDC does. The problem here, of course, is that you'd think you could dispense altogether with z/XDC running as an ESTAEX if you use TRAP2 instructions, but you can't. (At least not yet you can't.) You still need z/XDC to exist as an ESTAEX in order to catch the 0D3-13 abends so that it can know when Trap Handler Exit setup is needed. [sigh] However, the good news is that I'm currently working on easier ways to cause Trap Handler Exits to be installed. I expect to have that published in a month or few. Then it will become much more feasible to let z/XDC use TRAP2-type breakpoints without z/XDC also having to be present as an ESTAEX. This will make debugging much easier for programs having numerous, ephemeral ESTAEs popping up everywhere. (LE code is an example of such.) This will definitely help our c/XDC users a lot! (Our assembler customers should like it too.) Dave Cole, Developer dbc...@gmail.com (personal) dbc...@colesoft.com (business) 540-456-6518 (cell) At 3/1/2023 11:34 PM, Ed Jaffe wrote: On 3/1/2023 4:01 PM, Bernd Oppolzer wrote: Am 01.03.2023 um 19:51 schrieb Martin Trübner: I know of one big z/OS installation that has a debugger in use that uses TRAP (and the author is on IBM-main as well) That's me ... but as I said in the other mail, I am not the author of the debugger; I am only the maintainer today, and I changed the breakpoint mechanism (was: S0C1) by TRAP in the 2010 time frame. He might have been referring to z/XDC. ColeSoft acquired zDebug many years ago, which used TRAP exclusively, and incorporated much of that technology into z/XDC. IIRC, you must use the 0C1/ESTAEX method only once at initial entry. After that, you can switch over to TRAP (which is advantageous)... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- 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
Re: Full TRAP feature support [was: RE: Re: z/OS 3.1 Announcement US Letter]
On 3/1/2023 4:01 PM, Bernd Oppolzer wrote: Am 01.03.2023 um 19:51 schrieb Martin Trübner: I know of one big z/OS installation that has a debugger in use that uses TRAP (and the author is on IBM-main as well) That's me ... but as I said in the other mail, I am not the author of the debugger; I am only the maintainer today, and I changed the breakpoint mechanism (was: S0C1) by TRAP in the 2010 time frame. He might have been referring to z/XDC. ColeSoft acquired zDebug many years ago, which used TRAP exclusively, and incorporated much of that technology into z/XDC. IIRC, you must use the 0C1/ESTAEX method only once at initial entry. After that, you can switch over to TRAP (which is advantageous)... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Full TRAP feature support [was: RE: Re: z/OS 3.1 Announcement US Letter]
Am 01.03.2023 um 19:51 schrieb Martin Trübner: I know of one big z/OS installation that has a debugger in use that uses TRAP (and the author is on IBM-main as well) That's me ... but as I said in the other mail, I am not the author of the debugger; I am only the maintainer today, and I changed the breakpoint mechanism (was: S0C1) by TRAP in the 2010 time frame. Kind regards Bernd -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Full TRAP feature support [was: RE: Re: z/OS 3.1 Announcement US Letter]
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 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: 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). 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 a
Re: Full TRAP feature support [was: RE: Re: z/OS 3.1 Announcement US Letter]
Traditionally, the business case would have been that a debugging facility like this led to increased ability to exploit the platform, thus leading to more usage and more sales. Whether that still applies-whether IBM is interested in that for IBM zSystems-is unclear. With cloud, cloud, and more cloud, maybe not so much? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Full TRAP feature support [was: RE: Re: z/OS 3.1 Announcement US Letter]
I did develop a fully featured debugger solely on TRAP for VSE. I did that in 2000 as proof of concept or better to show that TRAP is not there for "year 200o fix up" as pops did say at that time. Originally it was object code only in CICS (just to see that it works)- meanwhile I support CICS and batch as well as debugging source code. I am semi retired now- but the tool is still available for free for a VSE environment. It supports z-arch including the z14. Because of the only use of TRAP to intercept it doe not need to know every instruction. What I like to say: pops has everything needed, but a software supported API would be great. I know of one big z/OS installation that has a debugger in use that uses TRAP (and the author is on IBM-main as well) Mentioning software vendors- there is a debugger called z/TDF from Arney Software - runs on z/OS and explored TRAP as well. Chuck is a good friend and I can see/imagine roots of his debugger in talks we had (and it is way younger than mine)MINE) during various real life meeting (in bars) we had. Best Martin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Full TRAP feature support [was: RE: Re: z/OS 3.1 Announcement US Letter]
One potential business justification for IBM would be "to sell the hardware that contains this spiffy feature." Isn't that essentially the business justification for *all* new z/OS features? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter Sent: Wednesday, March 1, 2023 8:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Full TRAP feature support [was: RE: Re: z/OS 3.1 Announcement US Letter] <*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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Full TRAP feature support [was: RE: Re: z/OS 3.1 Announcement US Letter]
<*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 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: 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). 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
