Re: ECVTDUCU & "trap" condition in z/OS
Peter, Thanks for the reply. But there is still the second question I asked - Can you say if there is any (near?) future possibility of a PC or SVC interface that would permit application-level code (problem state, non-zero-key) to use the TRAP facility? Such a facility would make many application-level assembler debugging tools (including and maybe especially the CBT collection) far more efficient and useful than is currently possible via ESTAEX or BAKR/PR methodologies. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Tuesday, November 21, 2017 7:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ECVTDUCU & "trap" condition in z/OS EXTERNAL: This email originated from outside of Broadridge. Do not click any links or open any attachments unless you trust the sender and know the content is safe. There is no additional documentation and there are no other references because there is no particular need for there to be. If you are using the trap instructions then you know (or need to know) about the trap control block and that the trap instructions architecture requires you to provide information controlling the traps within the dispatchable unit control table (DUCT). This pointer (and the service behind it) was created so that individual trap exploiters would not code these updates themselves because they were more likely to get it wrong than z/OS development is and were more likely not to be in a position to react to architectural changes (such as happened when z/Architecture was introduced) than z/OS development is. 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 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
Re: ECVTDUCU & "trap" condition in z/OS
On Tue, Nov 21, 2017 at 6:55 AM, Peter Relson wrote: > There is no additional documentation and there are no other references > because there is no particular need for there to be. > > If you are using the trap instructions then you know (or need to know) > about the trap control block and that the trap instructions architecture > requires you to provide information controlling the traps within the > dispatchable unit control table (DUCT). This pointer (and the service > behind it) was created so that individual trap exploiters would not code > these updates themselves because they were more likely to get it wrong > than z/OS development is and were more likely not to be in a position to > react to architectural changes (such as happened when z/Architecture was > introduced) than z/OS development is. > > Peter Relson > z/OS Core Technology Design > So, it is GUPI. But it is not going to be documented in a manual such as "Authorized Assembler Services Guide". IOW, as the preacher said in "Blazing Saddles", "Son, you're on your own!" -- I have a theory that it's impossible to prove anything, but I can't prove it. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ECVTDUCU & "trap" condition in z/OS
There is no additional documentation and there are no other references because there is no particular need for there to be. If you are using the trap instructions then you know (or need to know) about the trap control block and that the trap instructions architecture requires you to provide information controlling the traps within the dispatchable unit control table (DUCT). This pointer (and the service behind it) was created so that individual trap exploiters would not code these updates themselves because they were more likely to get it wrong than z/OS development is and were more likely not to be in a position to react to architectural changes (such as happened when z/Architecture was introduced) than z/OS development is. 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: ECVTDUCU & "trap" condition in z/OS
Sounds good to me EXCEPT for the "key 0, supervisor state" requirement. Sounds like we also need a system-supplied PC service that can be invoked from normal non-supervisor-state, non-zero-key application code to utilize the TRAP facilities (both enabling and disabling). Peter R. or John E., would you care to comment on this? Is there any chance that normal application-level code will be able use this facility any time soon? And yes, I understand that you cannot comment on future directions, but any clue would be helpful. At least we would have a some idea how long we have to wait for it. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, November 20, 2017 11:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ECVTDUCU & "trap" condition in z/OS EXTERNAL: This email originated from outside of Broadridge. Do not click any links or open any attachments unless you trust the sender and know the content is safe. On Mon, Nov 20, 2017 at 10:36 AM, Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > That is interesting John. No such field in my V2.1 MODGEN library > member IHAECVT. What offset it that at in your copy? > Apparently came in with 2.2 https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.iead100/iead100662.htm 268 (10C) ADDRESS 4 ECVTDUCU "V(IEAVDUCU)" - DUCT update - A value of 0 in ECVTDUCU means that the function is not available - Caller must be AMODE 31 or 64, key 0, supervisor state - Task mode - Primary ASC mode - Any P, Any S, Any H - To invoke the service: - Set GR 1 to 1 to indicate to update the TRAP Control Block Address - Set GR 0 to the address of the doubleword aligned TRAP Control Block Address (below 2G). Bits 0-31 of 64-bit GR0 are ignored. A non-zero value in bits 32-63 will enable the TRAP function. When enabling, bit 63 is ignored. Bits 61-62 must be 0. Use a value of 0 in bits 32-63 to disable the TRAP function. - Load ECVTDUCU into GR 15. Do not use the LLGT instruction. You do not need to set bits 0-31 of 64-bit GR 15. - If AMODE 64, issue BASSM 14,15 If AMODE 31, issue BASR 14,15 or BASSM 14,15 - Upon return from the service - 31-bit GRs 2-13, high halves 2-14, and ARs 2-14 will be preserved. Other GRs, high halves, and ARs may be used as work registers by the system. - On return R15 contains a return code 0 - success 8 - bad value in register 1 12 - TRAP update request in SRB mode > > One would HOPE such a field would be used by full z/OS support for > actually USING the TRAPx functionality (along with the several > compare-and-trap instructions too). > > Perhaps a "future use" field? > > Peter > > -- 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
Re: ECVTDUCU & "trap" condition in z/OS
On Mon, Nov 20, 2017 at 10:36 AM, Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > That is interesting John. No such field in my V2.1 MODGEN library member > IHAECVT. What offset it that at in your copy? > Apparently came in with 2.2 https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.iead100/iead100662.htm 268 (10C) ADDRESS 4 ECVTDUCU "V(IEAVDUCU)" - DUCT update - A value of 0 in ECVTDUCU means that the function is not available - Caller must be AMODE 31 or 64, key 0, supervisor state - Task mode - Primary ASC mode - Any P, Any S, Any H - To invoke the service: - Set GR 1 to 1 to indicate to update the TRAP Control Block Address - Set GR 0 to the address of the doubleword aligned TRAP Control Block Address (below 2G). Bits 0-31 of 64-bit GR0 are ignored. A non-zero value in bits 32-63 will enable the TRAP function. When enabling, bit 63 is ignored. Bits 61-62 must be 0. Use a value of 0 in bits 32-63 to disable the TRAP function. - Load ECVTDUCU into GR 15. Do not use the LLGT instruction. You do not need to set bits 0-31 of 64-bit GR 15. - If AMODE 64, issue BASSM 14,15 If AMODE 31, issue BASR 14,15 or BASSM 14,15 - Upon return from the service - 31-bit GRs 2-13, high halves 2-14, and ARs 2-14 will be preserved. Other GRs, high halves, and ARs may be used as work registers by the system. - On return R15 contains a return code 0 - success 8 - bad value in register 1 12 - TRAP update request in SRB mode > > One would HOPE such a field would be used by full z/OS support for > actually USING the TRAPx functionality (along with the several > compare-and-trap instructions too). > > Perhaps a "future use" field? > > Peter > > -- I have a theory that it's impossible to prove anything, but I can't prove it. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ECVTDUCU & "trap" condition in z/OS
That is interesting John. No such field in my V2.1 MODGEN library member IHAECVT. What offset it that at in your copy? One would HOPE such a field would be used by full z/OS support for actually USING the TRAPx functionality (along with the several compare-and-trap instructions too). Perhaps a "future use" field? Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, November 20, 2017 10:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ECVTDUCU & "trap" condition in z/OS EXTERNAL: This email originated from outside of Broadridge. Do not click any links or open any attachments unless you trust the sender and know the content is safe. I just stumbled upon this field in SYS1.MODGEN, member IHAECVT. This appears at first glance to be for the TRAP, TRAP4, and perhaps the AND TRAP instructions. But I don't really see _anything_ else something> in SYS1.MACLIB or SYS1.MODGEN that references this field. Anybody got a link to the secret documentation? Or is it one of those " but then I'd be forced to kill you" type situations. -- 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
ECVTDUCU & "trap" condition in z/OS
I just stumbled upon this field in SYS1.MODGEN, member IHAECVT. This appears at first glance to be for the TRAP, TRAP4, and perhaps the AND TRAP instructions. But I don't really see _anything_ else in SYS1.MACLIB or SYS1.MODGEN that references this field. Anybody got a link to the secret documentation? Or is it one of those " but then I'd be forced to kill you" type situations. -- I have a theory that it's impossible to prove anything, but I can't prove it. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
