Re: Use of the TRAPx Instructions

[Gerhard Postpischil]

On 4/12/2013 8:22 AM, Shmuel Metz (Seymour J.) wrote:

So you did your own GETMAIN for the IRB and the IQE/RQE?


No; they are hardcoded.

Gerhard Postpischil
Bradford, Vermont

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Use of the TRAPx Instructions

[Shmuel Metz (Seymour J.)]

In <5165dc62.1090...@valley.net>, on 04/10/2013
   at 05:40 PM, Gerhard Postpischil  said:

>FSVO normal. CIRB uses either an SVC 43, or its branch entry, and f
>or my use the 2nd level exit effector was shorter (both OS/360 and
>MVS).

So you did your own GETMAIN for the IRB and the IQE/RQE?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Use of the TRAPx Instructions

[Shmuel Metz (Seymour J.)]

In <516567cd.1040...@phoenixsoftware.com>, on 04/10/2013
   at 06:23 AM, Ed Jaffe  said:

>I assume these days most people use SCHEDIRB instead of CIRB.

For new z/OS code, I would hope so. As Gerhard noted, some people are
writing OS/VS2 code to run under Hercules; I'd probably use
conditional assembly and code both ways.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Use of the TRAPx Instructions

[Gerhard Postpischil]

On 4/10/2013 9:08 AM, Shmuel Metz (Seymour J.) wrote:

Wasn't CIRB still the normal way to create an IRB? And didn't CVT0EF00
always point to the Stage II Exit Effector?


FSVO normal. CIRB uses either an SVC 43, or its branch entry, and for my 
use the 2nd level exit effector was shorter (both OS/360 and MVS).


Gerhard Postpischil
Bradford, Vermont

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Use of the TRAPx Instructions

[Gerhard Postpischil]

On 4/10/2013 9:23 AM, Ed Jaffe wrote:

I assume these days most people use SCHEDIRB instead of CIRB. Certainly,
we do.


Some of us contribute to the Hercules/MVS projects, and I like to keep 
my code as compatible as possible. As a last resort I use conditional 
assemblies, but generally it's easier to encapsulate special code in 
subroutines.


Gerhard Postpischil
Bradford, Vermont

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Use of the TRAPx Instructions

[Ed Jaffe]

On 4/10/2013 6:08 AM, Shmuel Metz (Seymour J.) wrote:

In <5164cb34.3010...@valley.net>, on 04/09/2013
at 10:15 PM, Gerhard Postpischil  said:


The MVS version does not use CIRB, nor does it use the Master
Scheduler;  instead it calls CVT0EF00 directly to schedule an IRB and
IQE.

Wasn't CIRB still the normal way to create an IRB? And didn't CVT0EF00
always point to the Stage II Exit Effector?


I assume these days most people use SCHEDIRB instead of CIRB. Certainly, 
we do.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Use of the TRAPx Instructions

[Shmuel Metz (Seymour J.)]

In <5164cb34.3010...@valley.net>, on 04/09/2013
   at 10:15 PM, Gerhard Postpischil  said:

>The MVS version does not use CIRB, nor does it use the Master
>Scheduler;  instead it calls CVT0EF00 directly to schedule an IRB and
>IQE.

Wasn't CIRB still the normal way to create an IRB? And didn't CVT0EF00
always point to the Stage II Exit Effector?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Use of the TRAPx Instructions

[Shmuel Metz (Seymour J.)]

In <00e201ce3576$6cb2bff0$46183fd0$@austin.rr.com>, on 04/09/2013
   at 06:03 PM, Kenneth Wilkerson  said:

>TDF intercepts content supervision (LOAD,
>XCTL, LINK and ATTACH)

What about SYNCH?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Use of the TRAPx Instructions

[Kenneth Wilkerson]

Setting up the trap environment requires authorization and can easily be done 
by a non-space switch PC setup by an authorized server. The execution of a 
TRAPx instruction is not authorized and executes under the state of the program 
being trapped.  So, NO, there are no system integrity issues when debugging 
unauthorized programs.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Wednesday, April 10, 2013 5:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Use of the TRAPx Instructions

On Tue, 9 Apr 2013 16:17:25 -0500, Kenneth Wilkerson wrote:

>You have to
>be able to acquire key 0 to even examine the DUCT let alone modify the 
>DUCT to define the required trap control blocks. This means, of course, 
>that the application creating the trap environment must be authorized.

Doesn't that mean that it is difficult at best to ensure system integrity when 
debugging non-authorized code?

--
Tom Marchant

--
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: Use of the TRAPx Instructions

[Shane Ginnane]

And once again we have evidence of why it is worth putting up with all the 
drivel this list tosses up in the expectation that the (all too) occasional 
gems are worthwhile waiting for.

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Use of the TRAPx Instructions

[Tom Marchant]

On Tue, 9 Apr 2013 16:17:25 -0500, Kenneth Wilkerson wrote:

>You have to
>be able to acquire key 0 to even examine the DUCT let alone modify the DUCT
>to define the required trap control blocks. This means, of course, that the
>application creating the trap environment must be authorized.

Doesn't that mean that it is difficult at best to ensure system integrity when 
debugging non-authorized code?

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Use of the TRAPx Instructions

[Chuck Arney]

Bernd, you should be fine because in your environment any async exits that
get dispatched will not have TRAP instructions in them.  Traps would
probably only be inserted into the exit code by a debugger.  And since with
our debugger, the code that gets control first for the exit is our code so
we can handle the problem before any Traps are allowed to occur.  It is an
issue with the design of the Trap facility, which we were already aware, but
there are a number of ways it can be overcome.

Chuck Arney
Arney Computer Systems

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Bernd Oppolzer
Sent: Tuesday, April 09, 2013 7:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Use of the TRAPx Instructions

Maybe, what's most important in this context:
the test driver supports only single threaded testing, no subtasking. So, if
I read your posts correctly, we should not have a problem, right?

Kind regards

Bernd



Am 10.04.2013 02:08, schrieb Bernd Oppolzer:
> Hello,
>
> I don't understand all of this discussion, but:
>
> we are using TRAP2 now for some time in our site specific debugging 
> tool without problems. I would like to know if you see a hidden 
> problem in our method of using it.
>
> Before switching to TRAP2, we did the same thing by catching 0C1 
> abends with ESPIE. The method goes like this:
>
> from the compile listing (PL/1 or ASSEMBLER), we get the offsets of 
> interesting points in the load module, for example loop starts and 
> ends, procedure starts and ends, if ... then ... else etc.; these so 
> called "structure blocks" are marked after initial load (in the past 
> by hex zero, now with TRAP2 instructions).
>
> Then the module is called by the test driver; the test driver also 
> builds the parameter data from the test case database etc.
>
> Then the test driver exit catches the TRAP2 interrupts (in the past 
> the 0C1 abends) and lists all the program activitiy. Of course, it 
> restores the original opcodes and resumes execution after each 
> interrupt.
>
> There is only one TRAP2 handler routine which is registered in the 
> DUCT at start of the testdriver, using a special SVC. This is the only 
> place in the whole installation where TRAP2 is used. The programs that 
> we are testing are all application programs, TCB mode, as far as I know.
> And: there will never be a second TRAP instruction before the handler 
> resumes using RP.
>
> Is there any risk that we will get into a situation like the one that 
> you described?
> We never encountered any problem, so far. The system is z/OS, too, of 
> course.
>
> Thank you, kind regards
>
> Bernd
>
>
>
>
> Am 09.04.2013 22:36, schrieb Morrison, Peter:
>> I have had extensive experience with the use of the TRAPx
>> (TRAP2/TRAP4) instructions in a z/OS environment.
>>
>> z/OS offers no support for setting up to enable them. Basically, you 
>> need to anchor things in the DUCT (Dispatchable Unit Control Table).
>> There is one DUCT set up for each TCB and SRB.  (Note that ONLY ONE 
>> DUCT is set up for a TCB - not one DUCT per RB level.  THIS IS VERY
>> IMPORTANT!) (preserving a specifically formatted DUCT is important, 
>> but is not relevant to the discussion below.  Just be aware that 
>> there are issues associated with it)
>>
>> Generally, you can regard TRAPx as a 'fancy branch'.  The target is 
>> the routine whose address is set up in the control blocks. The 
>> hardware saves all state in the 'trap save area' first.
>>
>> BUT, there is a very significant problem when using TRAPx with z/OS!  
>> When your trap routine gets control, system state is as before the 
>> TRAPx instructions was executed.  This includes the fact that 
>> interrupts are probably enabled.  Why does this matter?  Because, in 
>> z/OS, in TCB mode, if an interrupt occurs, processing of that 
>> interrupt could involved de-scheduling the TCB, deciding to request a 
>> new RB level, and later, redispatching the TCB, so that the new RB 
>> level will get control.
>>
>> This can lead to the following scenario:
>>
>> 1: TCB-mode code executes a TRAPx instruction
>> 2: The hardware saves all state (PSW/Regs) in the Trap Save Area
>> 3: The registered Trap handler routine is given control and starts 
>> executing...
>> 4: an interrupt occurs
>> 5: During processing of the interrupt, the current TCB has a new RB 
>> level stacked over it
>> 6: The TCB is resumed.  Execution now is for the new RB level
>> 7: The new code executes a TRAPx instruction
>> 8: The hardware saves all state in the Trap Save Area. BAZINGA!  The 

Re: Use of the TRAPx Instructions

[Kenneth Wilkerson]

Thanks. I forgot about that one. It is covered in Chapter 22 on Exits in the
Auth Assembler Guide. This would also be classified as a branch entry
intercept. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Gerhard Postpischil
Sent: Tuesday, April 09, 2013 9:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Use of the TRAPx Instructions

On 4/9/2013 7:03 PM, Kenneth Wilkerson wrote:
> So now specifically to asynchronous exits. There are 3 ways to 
> schedule asynchronous exits that I know of, by STIMER(M), by SCHEDIRB 
> and by the old, SCHEDXIT. If there are other ways, please let me know.

There is at least one other - see the CIRB macro. Before HASP, operators on
an OS/360 system had to issue an explicit START RDR command to read a job
stream. I had a parameterized facility (define command, alter, delete by
unit) that caused an unsolicited interrupt to a defined device to trigger
the appropriate command, thus obviating the need for the operator to start
the reader. For MVS I have a version with more flexibility - I can set an
ATI in designated UCBs, and issue any command in response to an interrupt.
This is handy for activating CRT terminals on a different floor (not all are
defined to VTAM).

The MVS version does not use CIRB, nor does it use the Master Scheduler;
instead it calls CVT0EF00 directly to schedule an IRB and IQE.

Gerhard Postpischil
Bradford, Vermont

--
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: Use of the TRAPx Instructions

[Gerhard Postpischil]

On 4/9/2013 7:03 PM, Kenneth Wilkerson wrote:

So now specifically to asynchronous exits. There are 3 ways to schedule
asynchronous exits that I know of, by STIMER(M), by SCHEDIRB and by the old,
SCHEDXIT. If there are other ways, please let me know.


There is at least one other - see the CIRB macro. Before HASP, operators 
on an OS/360 system had to issue an explicit START RDR command to read a 
job stream. I had a parameterized facility (define command, alter, 
delete by unit) that caused an unsolicited interrupt to a defined device 
to trigger the appropriate command, thus obviating the need for the 
operator to start the reader. For MVS I have a version with more 
flexibility - I can set an ATI in designated UCBs, and issue any command 
in response to an interrupt. This is handy for activating CRT terminals 
on a different floor (not all are defined to VTAM).


The MVS version does not use CIRB, nor does it use the Master Scheduler; 
instead it calls CVT0EF00 directly to schedule an IRB and IQE.


Gerhard Postpischil
Bradford, Vermont

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Use of the TRAPx Instructions

[Bernd Oppolzer]

Maybe, what's most important in this context:
the test driver supports only single threaded testing,
no subtasking. So, if I read your posts correctly,
we should not have a problem, right?

Kind regards

Bernd



Am 10.04.2013 02:08, schrieb Bernd Oppolzer:

Hello,

I don't understand all of this discussion, but:

we are using TRAP2 now for some time in our site
specific debugging tool without problems. I would like
to know if you see a hidden problem in our method of
using it.

Before switching to TRAP2, we did the same thing by
catching 0C1 abends with ESPIE. The method goes like this:

from the compile listing (PL/1 or ASSEMBLER), we get the
offsets of interesting points in the load module, for example
loop starts and ends, procedure starts and ends, if ... then ... else
etc.; these so called "structure blocks" are marked after initial load
(in the past by hex zero, now with TRAP2 instructions).

Then the module is called by the test driver; the test driver also
builds the parameter data from the test case database etc.

Then the test driver exit catches the TRAP2 interrupts (in the past
the 0C1 abends) and lists all the program activitiy. Of course, it
restores the original opcodes and resumes execution after each
interrupt.

There is only one TRAP2 handler routine which is registered in the
DUCT at start of the testdriver, using a special SVC. This is the only
place in the whole installation where TRAP2 is used. The programs that
we are testing are all application programs, TCB mode, as far as I know.
And: there will never be a second TRAP instruction before the handler
resumes using RP.

Is there any risk that we will get into a situation like the one that 
you described?
We never encountered any problem, so far. The system is z/OS, too, of 
course.


Thank you, kind regards

Bernd




Am 09.04.2013 22:36, schrieb Morrison, Peter:
I have had extensive experience with the use of the TRAPx 
(TRAP2/TRAP4) instructions in a z/OS environment.


z/OS offers no support for setting up to enable them. Basically, you 
need to anchor things in the DUCT (Dispatchable Unit Control Table).  
There is one DUCT set up for each TCB and SRB.  (Note that ONLY ONE 
DUCT is set up for a TCB - not one DUCT per RB level.  THIS IS VERY 
IMPORTANT!) (preserving a specifically formatted DUCT is important, 
but is not relevant to the discussion below.  Just be aware that 
there are issues associated with it)


Generally, you can regard TRAPx as a 'fancy branch'.  The target is 
the routine whose address is set up in the control blocks. The 
hardware saves all state in the 'trap save area' first.


BUT, there is a very significant problem when using TRAPx with z/OS!  
When your trap routine gets control, system state is as before the 
TRAPx instructions was executed.  This includes the fact that 
interrupts are probably enabled.  Why does this matter?  Because, in 
z/OS, in TCB mode, if an interrupt occurs, processing of that 
interrupt could involved de-scheduling the TCB, deciding to request a 
new RB level, and later, redispatching the TCB, so that the new RB 
level will get control.


This can lead to the following scenario:

1: TCB-mode code executes a TRAPx instruction
2: The hardware saves all state (PSW/Regs) in the Trap Save Area
3: The registered Trap handler routine is given control and starts 
executing...

4: an interrupt occurs
5: During processing of the interrupt, the current TCB has a new RB 
level stacked over it

6: The TCB is resumed.  Execution now is for the new RB level
7: The new code executes a TRAPx instruction
8: The hardware saves all state in the Trap Save Area. BAZINGA!  The 
old information is overwritten!
9: The registered trap handler routine is given control and starts 
executing...


Because the trap save area  has been overwritten, the lower-level 
handler, when it resumes execution, is not using correct 
information.  There is not even any way to know that this has occurred.


While the situation CAN be circumvented by preventing asynchronous RB 
stacking (there is a bit in the TCB for this), this can play havoc 
with debugging as, for example, asynchronous exits to do with I/O 
won't execute...


For the above reason, use of TRAPx instructions as a way to implement 
breakpoints in code that executes on z/OS in TCB mode is not a good 
idea...


Peter Morrison
Principal Software Architect
CA
6 Eden Park Drive
North Ryde NSW 2113
Tel: 02 8898 2624
Fax: 02 8898 2600
peter.morri...@ca.com

--
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



--
For IBM-MAIN subscribe / 

Re: Use of the TRAPx Instructions

[Bernd Oppolzer]

Hello,

I don't understand all of this discussion, but:

we are using TRAP2 now for some time in our site
specific debugging tool without problems. I would like
to know if you see a hidden problem in our method of
using it.

Before switching to TRAP2, we did the same thing by
catching 0C1 abends with ESPIE. The method goes like this:

from the compile listing (PL/1 or ASSEMBLER), we get the
offsets of interesting points in the load module, for example
loop starts and ends, procedure starts and ends, if ... then ... else
etc.; these so called "structure blocks" are marked after initial load
(in the past by hex zero, now with TRAP2 instructions).

Then the module is called by the test driver; the test driver also
builds the parameter data from the test case database etc.

Then the test driver exit catches the TRAP2 interrupts (in the past
the 0C1 abends) and lists all the program activitiy. Of course, it
restores the original opcodes and resumes execution after each
interrupt.

There is only one TRAP2 handler routine which is registered in the
DUCT at start of the testdriver, using a special SVC. This is the only
place in the whole installation where TRAP2 is used. The programs that
we are testing are all application programs, TCB mode, as far as I know.
And: there will never be a second TRAP instruction before the handler
resumes using RP.

Is there any risk that we will get into a situation like the one that 
you described?
We never encountered any problem, so far. The system is z/OS, too, of 
course.


Thank you, kind regards

Bernd




Am 09.04.2013 22:36, schrieb Morrison, Peter:

I have had extensive experience with the use of the TRAPx (TRAP2/TRAP4) 
instructions in a z/OS environment.

z/OS offers no support for setting up to enable them.  Basically, you need to 
anchor things in the DUCT (Dispatchable Unit Control Table).  There is one DUCT 
set up for each TCB and SRB.  (Note that ONLY ONE DUCT is set up for a TCB - 
not one DUCT per RB level.  THIS IS VERY IMPORTANT!) (preserving a specifically 
formatted DUCT is important, but is not relevant to the discussion below.  Just 
be aware that there are issues associated with it)

Generally, you can regard TRAPx as a 'fancy branch'.  The target is the routine 
whose address is set up in the control blocks.  The hardware saves all state in 
the 'trap save area' first.

BUT, there is a very significant problem when using TRAPx with z/OS!  When your 
trap routine gets control, system state is as before the TRAPx instructions was 
executed.  This includes the fact that interrupts are probably enabled.  Why 
does this matter?  Because, in z/OS, in TCB mode, if an interrupt occurs, 
processing of that interrupt could involved de-scheduling the TCB, deciding to 
request a new RB level, and later, redispatching the TCB, so that the new RB 
level will get control.

This can lead to the following scenario:

1: TCB-mode code executes a TRAPx instruction
2: The hardware saves all state (PSW/Regs) in the Trap Save Area
3: The registered Trap handler routine is given control and starts executing...
4: an interrupt occurs
5: During processing of the interrupt, the current TCB has a new RB level 
stacked over it
6: The TCB is resumed.  Execution now is for the new RB level
7: The new code executes a TRAPx instruction
8: The hardware saves all state in the Trap Save Area.  BAZINGA!  The old 
information is overwritten!
9: The registered trap handler routine is given control and starts executing...

Because the trap save area  has been overwritten, the lower-level handler, when 
it resumes execution, is not using correct information.  There is not even any 
way to know that this has occurred.

While the situation CAN be circumvented by preventing asynchronous RB stacking 
(there is a bit in the TCB for this), this can play havoc with debugging as, 
for example, asynchronous exits to do with I/O won't execute...

For the above reason, use of TRAPx instructions as a way to implement 
breakpoints in code that executes on z/OS in TCB mode is not a good idea...

Peter Morrison
Principal Software Architect
CA
6 Eden Park Drive
North Ryde NSW 2113
Tel: 02 8898 2624
Fax: 02 8898 2600
peter.morri...@ca.com

--
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: Use of the TRAPx Instructions

[Kenneth Wilkerson]

Peter, since you did such an excellent job of describing the problem, I've
decided to describe to you how TDF is going to handle asynchronous exits.
Before doing so, I need to clearly state that for the current release of the
product the asynchronous exit debugging is a restriction. Months ago I
looked into the problem and devised a solution but I didn't implement it
because I had many other things on my plate. Second, all of the technology
I'm about to describe exists in TDF right now. It's just a new
implementation of the same intercept technology already being used.

The TRAPx instruction alone is insufficient to accommodate full fledge
debugging. As you mentioned, its anchored off the Dispatchable Unit Control
Table (DUCT) so its scope is a dispatchable unit, a TCB or SRB. In a complex
system involving multiple tasks and multiple address spaces, this scope is
easily exceeded. So a mechanism must exist to automatically extend the scope
of the trap environment as the application grows in scope. The mechanism
used by TDF is called Dynamic Program Intercepts. Without going into great
detail, suffice it to say that TDF intercepts content supervision (LOAD,
XCTL, LINK and ATTACH) , RTM exit and key schedule service calls. So when a
new task is attached, through commands, you can define whether TDF
automatically sets up the trap environment for a new task. You actually
attach a TDF program that sets up the environment and transfers control to
your program with a newly setup trap environment. When you create an RTM
exit, a small program in TDF actually gets control and it wraps your RTM
exits. TDF can also wrap key schedule services like IEAMSCHD so that when an
SRB is scheduled, it initializes the DUCT just as if the SRB had a hook
macro assembled into it. The bottom line is that the MVS implementation (or
lack of it) of the TRAP instruction can be compensated through intercept
technology.

So now specifically to asynchronous exits. There are 3 ways to schedule
asynchronous exits that I know of, by STIMER(M), by SCHEDIRB and by the old,
SCHEDXIT. If there are other ways, please let me know. Since I haven't
really started coding this I haven't finished all my research. STIMER(M) is
by SVC. The existing TDF SVC intercept can be easily extended to include
STIMER (M) . SCHEDIRB and SCHEDXIT are branch entry calls. TDF provides a
mechanism called Branch Entry intercepts which are very special TRAP
breakpoints that redirect execution of Branch entry calls (like SETFRR for
example) to an intercept similar to the way SVC and PC interception works.
Regardless of the type of schedule service, TDF replaces your exit address
with a program that would wrap your exit. The front end would "stack" the
prior trap environment and the back end would "unstack" it.

This is a simple explanation to a complex problem.

Kenneth

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Binyamin Dissen
Sent: Tuesday, April 09, 2013 4:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Use of the TRAPx Instructions

Looking as the DUCT, it also contains an indication of base address space or
subspace.

I would think that an ASYNC exit/IRB would not useethe basespace indicater
of the current RB.

On Tue, 9 Apr 2013 16:17:25 -0500 Kenneth Wilkerson 
wrote:

:>You are certainly correct about the z/OS implementation of the TRAPx
:>instruction. I often wondered why the hardware designers decided to
:>implement it such that it inherits the user state and not a predefined
state :>and why they didn't provide a service to "register" trap interfaces
so they :>could be shared or the asynchronous exit issue could be solved.
You have to :>be able to acquire key 0 to even examine the DUCT let alone
modify the DUCT :>to define the required trap control blocks. This means, of
course, that the :>application creating the trap environment must be
authorized.
:>
:> But despite these z/OS limitations,  in my mind, the asynchronous exit
:>issue is just a restriction. It's no bigger a restriction then the fact
that :>the TRAP can't be executed in HOME ASC (SAC 768) or Secondary ASC
mode (SAC
:>256) or in transaction processing. Your scenario involves the asynchronous
:>exit also invoking a TRAPx instruction. So simply stated, asynchronous
exits :>cannot be debugged using the TRAPx instruction without a service to
:>determine if the TRAP control blocks are currently in use and perform a
TRAP :>stack function. But even this problem can be solved with a little
extra code :>(a PC routine) that stacks the current trap save area if it's
in use. 
:>
:>Certainly, the TRAPx instruction has fewer limitations than other
available :>methods. Every method is going to have restrictions. In my
asynchronous :>exits, I typically simply update a control block and post a
task to proce

Re: Use of the TRAPx Instructions

[Binyamin Dissen]

Looking as the DUCT, it also contains an indication of base address space or
subspace.

I would think that an ASYNC exit/IRB would not useethe basespace indicater of
the current RB.

On Tue, 9 Apr 2013 16:17:25 -0500 Kenneth Wilkerson 
wrote:

:>You are certainly correct about the z/OS implementation of the TRAPx
:>instruction. I often wondered why the hardware designers decided to
:>implement it such that it inherits the user state and not a predefined state
:>and why they didn't provide a service to "register" trap interfaces so they
:>could be shared or the asynchronous exit issue could be solved. You have to
:>be able to acquire key 0 to even examine the DUCT let alone modify the DUCT
:>to define the required trap control blocks. This means, of course, that the
:>application creating the trap environment must be authorized.
:>
:> But despite these z/OS limitations,  in my mind, the asynchronous exit
:>issue is just a restriction. It's no bigger a restriction then the fact that
:>the TRAP can't be executed in HOME ASC (SAC 768) or Secondary ASC mode (SAC
:>256) or in transaction processing. Your scenario involves the asynchronous
:>exit also invoking a TRAPx instruction. So simply stated, asynchronous exits
:>cannot be debugged using the TRAPx instruction without a service to
:>determine if the TRAP control blocks are currently in use and perform a TRAP
:>stack function. But even this problem can be solved with a little extra code
:>(a PC routine) that stacks the current trap save area if it's in use. 
:>
:>Certainly, the TRAPx instruction has fewer limitations than other available
:>methods. Every method is going to have restrictions. In my asynchronous
:>exits, I typically simply update a control block and post a task to process
:>whatever it is that I'm trying to process. 
:>
:>Kenneth, TDF Architect
:>
:>-Original Message-
:>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:>Behalf Of Morrison, Peter
:>Sent: Tuesday, April 09, 2013 3:37 PM
:>To: IBM-MAIN@LISTSERV.UA.EDU
:>Subject: Use of the TRAPx Instructions
:>
:>I have had extensive experience with the use of the TRAPx (TRAP2/TRAP4)
:>instructions in a z/OS environment.
:>
:>z/OS offers no support for setting up to enable them.  Basically, you need
:>to anchor things in the DUCT (Dispatchable Unit Control Table).  There is
:>one DUCT set up for each TCB and SRB.  (Note that ONLY ONE DUCT is set up
:>for a TCB - not one DUCT per RB level.  THIS IS VERY IMPORTANT!) (preserving
:>a specifically formatted DUCT is important, but is not relevant to the
:>discussion below.  Just be aware that there are issues associated with it)
:>
:>Generally, you can regard TRAPx as a 'fancy branch'.  The target is the
:>routine whose address is set up in the control blocks.  The hardware saves
:>all state in the 'trap save area' first.
:>
:>BUT, there is a very significant problem when using TRAPx with z/OS!  When
:>your trap routine gets control, system state is as before the TRAPx
:>instructions was executed.  This includes the fact that interrupts are
:>probably enabled.  Why does this matter?  Because, in z/OS, in TCB mode, if
:>an interrupt occurs, processing of that interrupt could involved
:>de-scheduling the TCB, deciding to request a new RB level, and later,
:>redispatching the TCB, so that the new RB level will get control.  
:>
:>This can lead to the following scenario:
:>
:>1: TCB-mode code executes a TRAPx instruction
:>2: The hardware saves all state (PSW/Regs) in the Trap Save Area
:>3: The registered Trap handler routine is given control and starts
:>executing...
:>4: an interrupt occurs
:>5: During processing of the interrupt, the current TCB has a new RB level
:>stacked over it
:>6: The TCB is resumed.  Execution now is for the new RB level
:>7: The new code executes a TRAPx instruction
:>8: The hardware saves all state in the Trap Save Area.  BAZINGA!  The old
:>information is overwritten!
:>9: The registered trap handler routine is given control and starts
:>executing...
:>
:>Because the trap save area  has been overwritten, the lower-level handler,
:>when it resumes execution, is not using correct information.  There is not
:>even any way to know that this has occurred.
:>
:>While the situation CAN be circumvented by preventing asynchronous RB
:>stacking (there is a bit in the TCB for this), this can play havoc with
:>debugging as, for example, asynchronous exits to do with I/O won't
:>execute...
:>
:>For the above reason, use of TRAPx instructions as a way to implement
:>breakpoints in code that executes on z/OS in TCB mode is not a good idea...
:>
:>Peter Morrison
:>Principal Software Architect
:>

Re: Use of the TRAPx Instructions

[Kenneth Wilkerson]

You are certainly correct about the z/OS implementation of the TRAPx
instruction. I often wondered why the hardware designers decided to
implement it such that it inherits the user state and not a predefined state
and why they didn't provide a service to "register" trap interfaces so they
could be shared or the asynchronous exit issue could be solved. You have to
be able to acquire key 0 to even examine the DUCT let alone modify the DUCT
to define the required trap control blocks. This means, of course, that the
application creating the trap environment must be authorized.

 But despite these z/OS limitations,  in my mind, the asynchronous exit
issue is just a restriction. It's no bigger a restriction then the fact that
the TRAP can't be executed in HOME ASC (SAC 768) or Secondary ASC mode (SAC
256) or in transaction processing. Your scenario involves the asynchronous
exit also invoking a TRAPx instruction. So simply stated, asynchronous exits
cannot be debugged using the TRAPx instruction without a service to
determine if the TRAP control blocks are currently in use and perform a TRAP
stack function. But even this problem can be solved with a little extra code
(a PC routine) that stacks the current trap save area if it's in use. 

Certainly, the TRAPx instruction has fewer limitations than other available
methods. Every method is going to have restrictions. In my asynchronous
exits, I typically simply update a control block and post a task to process
whatever it is that I'm trying to process. 

Kenneth, TDF Architect

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Morrison, Peter
Sent: Tuesday, April 09, 2013 3:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Use of the TRAPx Instructions

I have had extensive experience with the use of the TRAPx (TRAP2/TRAP4)
instructions in a z/OS environment.

z/OS offers no support for setting up to enable them.  Basically, you need
to anchor things in the DUCT (Dispatchable Unit Control Table).  There is
one DUCT set up for each TCB and SRB.  (Note that ONLY ONE DUCT is set up
for a TCB - not one DUCT per RB level.  THIS IS VERY IMPORTANT!) (preserving
a specifically formatted DUCT is important, but is not relevant to the
discussion below.  Just be aware that there are issues associated with it)

Generally, you can regard TRAPx as a 'fancy branch'.  The target is the
routine whose address is set up in the control blocks.  The hardware saves
all state in the 'trap save area' first.

BUT, there is a very significant problem when using TRAPx with z/OS!  When
your trap routine gets control, system state is as before the TRAPx
instructions was executed.  This includes the fact that interrupts are
probably enabled.  Why does this matter?  Because, in z/OS, in TCB mode, if
an interrupt occurs, processing of that interrupt could involved
de-scheduling the TCB, deciding to request a new RB level, and later,
redispatching the TCB, so that the new RB level will get control.  

This can lead to the following scenario:

1: TCB-mode code executes a TRAPx instruction
2: The hardware saves all state (PSW/Regs) in the Trap Save Area
3: The registered Trap handler routine is given control and starts
executing...
4: an interrupt occurs
5: During processing of the interrupt, the current TCB has a new RB level
stacked over it
6: The TCB is resumed.  Execution now is for the new RB level
7: The new code executes a TRAPx instruction
8: The hardware saves all state in the Trap Save Area.  BAZINGA!  The old
information is overwritten!
9: The registered trap handler routine is given control and starts
executing...

Because the trap save area  has been overwritten, the lower-level handler,
when it resumes execution, is not using correct information.  There is not
even any way to know that this has occurred.

While the situation CAN be circumvented by preventing asynchronous RB
stacking (there is a bit in the TCB for this), this can play havoc with
debugging as, for example, asynchronous exits to do with I/O won't
execute...

For the above reason, use of TRAPx instructions as a way to implement
breakpoints in code that executes on z/OS in TCB mode is not a good idea...

Peter Morrison
Principal Software Architect
CA
6 Eden Park Drive
North Ryde NSW 2113
Tel: 02 8898 2624
Fax: 02 8898 2600
peter.morri...@ca.com

--
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

Use of the TRAPx Instructions

[Morrison, Peter]

I have had extensive experience with the use of the TRAPx (TRAP2/TRAP4) 
instructions in a z/OS environment.

z/OS offers no support for setting up to enable them.  Basically, you need to 
anchor things in the DUCT (Dispatchable Unit Control Table).  There is one DUCT 
set up for each TCB and SRB.  (Note that ONLY ONE DUCT is set up for a TCB - 
not one DUCT per RB level.  THIS IS VERY IMPORTANT!) (preserving a specifically 
formatted DUCT is important, but is not relevant to the discussion below.  Just 
be aware that there are issues associated with it)

Generally, you can regard TRAPx as a 'fancy branch'.  The target is the routine 
whose address is set up in the control blocks.  The hardware saves all state in 
the 'trap save area' first.

BUT, there is a very significant problem when using TRAPx with z/OS!  When your 
trap routine gets control, system state is as before the TRAPx instructions was 
executed.  This includes the fact that interrupts are probably enabled.  Why 
does this matter?  Because, in z/OS, in TCB mode, if an interrupt occurs, 
processing of that interrupt could involved de-scheduling the TCB, deciding to 
request a new RB level, and later, redispatching the TCB, so that the new RB 
level will get control.  

This can lead to the following scenario:

1: TCB-mode code executes a TRAPx instruction
2: The hardware saves all state (PSW/Regs) in the Trap Save Area
3: The registered Trap handler routine is given control and starts executing...
4: an interrupt occurs
5: During processing of the interrupt, the current TCB has a new RB level 
stacked over it
6: The TCB is resumed.  Execution now is for the new RB level
7: The new code executes a TRAPx instruction
8: The hardware saves all state in the Trap Save Area.  BAZINGA!  The old 
information is overwritten!
9: The registered trap handler routine is given control and starts executing...

Because the trap save area  has been overwritten, the lower-level handler, when 
it resumes execution, is not using correct information.  There is not even any 
way to know that this has occurred.

While the situation CAN be circumvented by preventing asynchronous RB stacking 
(there is a bit in the TCB for this), this can play havoc with debugging as, 
for example, asynchronous exits to do with I/O won't execute...

For the above reason, use of TRAPx instructions as a way to implement 
breakpoints in code that executes on z/OS in TCB mode is not a good idea...

Peter Morrison
Principal Software Architect
CA 
6 Eden Park Drive
North Ryde NSW 2113 
Tel: 02 8898 2624
Fax: 02 8898 2600
peter.morri...@ca.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN