Re: ECVTDUCU & "trap" condition in z/OS

[Farley, Peter x23353]

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

[John McKown]

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

[Peter Relson]

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

[Farley, Peter x23353]

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

[John McKown]

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

[Farley, Peter x23353]

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

[John McKown]

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