Discussion:
Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?
(too old to reply)
Charles Mills
2017-08-27 18:01:17 UTC
Permalink
Raw Message
Starting a new thread. Here is the fundamental problem. (If you were
following the other thread -- I am now testing without my own ESTAE, just
vanilla LE.)

An AMODE 31 C++ program provides a signal handler. It will get driven for
your basic S0C1 or S0C4.

But if the C++ program calls an assembler subroutine that gets a S0C4 while
in AMODE 64 it seems to boggle LE and the signal routine is not driven.

At least that is what I am seeing. Does anyone know of a way to get LE to
drive an AMODE 31 C/C++ signal routine even if the exception occurred in
AMODE 64?

Charles

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
B***@T-ONLINE.DE
2017-08-27 18:36:38 UTC
Permalink
Raw Message
is my understsnding correct that the LE Error handler is activated but has
Problems because of the 64 Bit Situation in the Ceecib and then the non
handled 0c4 occurs? If so, would it help if you used your own LE Error
handler? or modify the Ceecib contents in a sensible way before percolating
to LE?


------------------------------------------------------------------------
Gesendet mit der Telekom Mail App
<http://www.t-online.de/service/redir/email_app_android_sendmail_footer.htm>



--- Original-Nachricht ---
Von: Charles Mills
Betreff: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?
Datum: 27.08.2017, 20:02 Uhr
An: IBM-***@LISTSERV.UA.EDU





Starting a new thread. Here is the fundamental problem. (If you were
following the other thread -- I am now testing without my own ESTAE, just
vanilla LE.)

An AMODE 31 C++ program provides a signal handler. It will get driven for
your basic S0C1 or S0C4.

But if the C++ program calls an assembler subroutine that gets a S0C4 while
in AMODE 64 it seems to boggle LE and the signal routine is not driven.

At least that is what I am seeing. Does anyone know of a way to get LE to
drive an AMODE 31 C/C++ signal routine even if the exception occurred in
AMODE 64?

Charles

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-08-27 19:43:43 UTC
Permalink
Raw Message
There is only one apparent "error" -- the original S0C4 in AMODE 64 assembler.

LE is silent as to what its problem is. There is no LE error message, just the usual sorts of S0C4 messages from MVS.

Yeah, my own LE error handler might help ...

I am thinking of trying setting AMODE 31 in the SDWA PSW16 (going back to my own ESTAE ahead of LE's) and seeing if that helps.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of ***@t-online.de
Sent: Sunday, August 27, 2017 2:38 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: AW: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

is my understsnding correct that the LE Error handler is activated but has Problems because of the 64 Bit Situation in the Ceecib and then the non handled 0c4 occurs? If so, would it help if you used your own LE Error handler? or modify the Ceecib contents in a sensible way before percolating to LE?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Bernd Oppolzer
2017-08-27 20:13:47 UTC
Permalink
Raw Message
can the AMODE 64 Assembler routine establish its own ESTAE routine
which takes precedence over LE? Don't know, if there is already ESPIE /
ESTAE
support for the 64 bit case (don't know much about AMODE 64 altogether).

I believe that with AMODE 31 this should be possible (establishing another
ESTAE routine, when LE is active), because IIRC this is what I did when
calling
C and PL/1 routines from APL ... the ESTAE exit catches the errors in the
C/PL1 region and writes the data from the APL interface; this is when LE is
still active, because APL allows to establish a persistent LE environment
before calling the "real" function.

This reminds me again about all our struggle with the LE error handling at
my former customers site. We wanted (in the early 90s) to keep our very
sophisticated error handling based on ESPIE / ESTAE and not having LE
doing anything
about this, so we ran with NOSPIE,NOSTAE all the time ... which worked
very good
in the beginning (this was inherited from the 1980s, when there was only
PL/1 and
ASSEMBLER, and it worked with the first C releases, too).

But then we had that problems with S0C8s introduced by C, so we had to run
with what was then called TRAP(ON). In the end we had to migrate all our
error handling logic to a "customer" LE error handler. This is what is
done until today
(AFAIK some special ESTAE handling is still active in the IMS/DC
environment,
the "customer" LE error handler did not work there correctly). I
finished working
for this customer at the end of 2014, so I don't know the details of today.

Kind regards

Bernd
Post by Charles Mills
There is only one apparent "error" -- the original S0C4 in AMODE 64 assembler.
LE is silent as to what its problem is. There is no LE error message, just the usual sorts of S0C4 messages from MVS.
Yeah, my own LE error handler might help ...
I am thinking of trying setting AMODE 31 in the SDWA PSW16 (going back to my own ESTAE ahead of LE's) and seeing if that helps.
Charles
-----Original Message-----
Sent: Sunday, August 27, 2017 2:38 PM
Subject: AW: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?
is my understsnding correct that the LE Error handler is activated but has Problems because of the 64 Bit Situation in the Ceecib and then the non handled 0c4 occurs? If so, would it help if you used your own LE Error handler? or modify the Ceecib contents in a sensible way before percolating to LE?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Hunkeler
2017-08-29 06:40:43 UTC
Permalink
Raw Message
Post by Bernd Oppolzer
I believe that with AMODE 31 this should be possible (establishing another
ESTAE routine, when LE is active), because IIRC this is what I did when
calling C and PL/1 routines from APL ...



Is it possible? Yes.
Is it supported by LE? No. Read my comment on Charle's previous thread.
--
Peter Hunkeler

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-08-27 20:14:18 UTC
Permalink
Raw Message
Post by Charles Mills
I am thinking of trying setting AMODE 31 in the SDWA PSW16 (going back to my own ESTAE ahead of LE's) and seeing if that helps.
It does indeed! Seems to solve the problem. LE is happy. It interprets all of the registers as 31-bit addresses, but most of them are anyway.

Need to work on this a little, but I have the key I think.

Unless someone else has the "right" way of doing this.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Charles Mills
Sent: Sunday, August 27, 2017 3:45 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

There is only one apparent "error" -- the original S0C4 in AMODE 64 assembler.

LE is silent as to what its problem is. There is no LE error message, just the usual sorts of S0C4 messages from MVS.

Yeah, my own LE error handler might help ...

I am thinking of trying setting AMODE 31 in the SDWA PSW16 (going back to my own ESTAE ahead of LE's) and seeing if that helps.

Charles

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Bernd Oppolzer
2017-08-27 20:22:42 UTC
Permalink
Raw Message
Once again:

is my understanding correct, that LE cannot handle the 64 bit situation
in the SDWA
correctly, and you repair this by modifying the contents of the SDWA in
your ESTAE routine,
before percolating to LE, that is: you are "fooling" LE, this way
repairing (?) the problem
that LE has?

IMO you should ask IBM for help on this;
if calling AMODE 64 Assembler routines is supported from LE HLL programs,
LE should be able to handle ABENDs that occur there correctly.

Kind regards

Bernd
Post by Charles Mills
Post by Charles Mills
I am thinking of trying setting AMODE 31 in the SDWA PSW16 (going back to my own ESTAE ahead of LE's) and seeing if that helps.
It does indeed! Seems to solve the problem. LE is happy. It interprets all of the registers as 31-bit addresses, but most of them are anyway.
Need to work on this a little, but I have the key I think.
Unless someone else has the "right" way of doing this.
Charles
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-08-27 21:00:34 UTC
Permalink
Raw Message
Yes, your understanding is correct.

Just to clarify one thing, the assembler routine is not AMODE 64 at the module level. It is always entered and exits (assuming no S0C4s!) in AMODE 31. But it uses SAM64 to access above the bar storage, and then SAM31 to get back again. Everything I am doing in terms of the calling is so far as I know utterly vanilla and legal. My extra ESTAE is not, but it is not part of the problem. If I take it out, LE behaves exactly the same as it does on percolation from my ESTAE recovery routine (as one would expect).

What do the IBMers on this list think? Is that something that might be desirable for LE to handle without having to be "fooled"?

LE fails to print the high register halves, for example

GPR0..... ********_000000C6 GPR1..... ********_00000020 GPR2..... ********_FFFFFFFF GPR3..... ********_00000002

If I had nothing better to do I would open an RFE on that. Even assuming AMODE 31, how can LE assume that the high halves of the registers are of no debugging value? 64-bit register arithmetic -- or even using the high halves of registers as a temporary holding area -- is a valid technique even in the absence of AMODE 64. The C/C++ compiler itself does so.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Bernd Oppolzer
Sent: Sunday, August 27, 2017 4:24 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

Once again:

is my understanding correct, that LE cannot handle the 64 bit situation in the SDWA correctly, and you repair this by modifying the contents of the SDWA in your ESTAE routine, before percolating to LE, that is: you are "fooling" LE, this way repairing (?) the problem that LE has?

IMO you should ask IBM for help on this; if calling AMODE 64 Assembler routines is supported from LE HLL programs, LE should be able to handle ABENDs that occur there correctly.

Kind regards

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2017-08-28 12:46:56 UTC
Permalink
Raw Message
I can only guess that this particular register dump comes from a
32-bit savearea. Deliberately masking off the high-halves when
available would be profoundly asinine. Say it ain't so, LE!

sas

On Sun, Aug 27, 2017 at 5:01 PM, Charles Mills <***@mcn.org> wrote:
...
Post by Charles Mills
LE fails to print the high register halves, for example
GPR0..... ********_000000C6 GPR1..... ********_00000020 GPR2..... ********_FFFFFFFF GPR3..... ********_00000002
If I had nothing better to do I would open an RFE on that. Even assuming AMODE 31, how can LE assume that the high halves of the registers are of no debugging value? 64-bit register arithmetic -- or even using the high halves of registers as a temporary holding area -- is a valid technique even in the absence of AMODE 64. The C/C++ compiler itself does so.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Hunkeler
2017-08-29 06:47:57 UTC
Permalink
Raw Message
Post by Charles Mills
If I had nothing better to do I would open an RFE on that. Even assuming AMODE 31, how can LE assume that the high halves of the registers are of no debugging value? 64-bit register arithmetic -- or even using the high halves of registers as a temporary holding area -- is a valid technique even in the absence of AMODE 64. The C/C++ compiler itself does so.
Have a look at the "Language Environment Programming Guide for 64-bit Virtual Addressing Mode" manual, chapter "Chapter 21. Assembler considerations". It has some description about AMODE 64 assembler. I browsed it quickly, only. It talks about XPLINK convention to be a prerequisite for AMODE 64 assembler in a LE supported way. I never did anything with XPLINK, so I cannot say how much effort this is, but maybe you can change your assembler code to be LE AMODE 64 compatible.
While your "SDWA hack" seems to work (today), it is cheating, as you said yourself. May hurt you, or your customer in the future.


--
Peter Hunkeler





----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-08-29 15:16:44 UTC
Permalink
Raw Message
So far as I have seen, the documentation does not consider nor address the
situation I have. It considers all-64-bit C with all-64-bit assembler, or
all-31-bit C with all-31-bit assembler. I have 31-bit assembler with a few
64-bit instructions, one of which happened to S0C4. I suppose one (or IBM)
could take the attitude "that's not allowed." But gee, why do people link
from C to assembler to begin with? To do things they cannot do in pure C! I
would say that addressing some data above the bar is a valid case of that.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: Monday, August 28, 2017 11:49 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: AW: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64
assembler?
Post by Charles Mills
If I had nothing better to do I would open an RFE on that. Even assuming
AMODE 31, how can LE assume that the high halves of the registers are of no
debugging value? 64-bit register arithmetic -- or even using the high halves
of registers as a temporary holding area -- is a valid technique even in the
absence of AMODE 64. The C/C++ compiler itself does so.


Have a look at the "Language Environment Programming Guide for 64-bit
Virtual Addressing Mode" manual, chapter "Chapter 21. Assembler
considerations". It has some description about AMODE 64 assembler. I browsed
it quickly, only. It talks about XPLINK convention to be a prerequisite for
AMODE 64 assembler in a LE supported way. I never did anything with XPLINK,
so I cannot say how much effort this is, but maybe you can change your
assembler code to be LE AMODE 64 compatible.
While your "SDWA hack" seems to work (today), it is cheating, as you said
yourself. May hurt you, or your customer in the future.


--
Peter Hunkeler





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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Don Poitras
2017-08-29 15:26:56 UTC
Permalink
Raw Message
But you _can_ address data above the bar in "pure" C. Just compile and link
the C code as 64-bit.
Post by Charles Mills
So far as I have seen, the documentation does not consider nor address the
situation I have. It considers all-64-bit C with all-64-bit assembler, or
all-31-bit C with all-31-bit assembler. I have 31-bit assembler with a few
64-bit instructions, one of which happened to S0C4. I suppose one (or IBM)
could take the attitude "that's not allowed." But gee, why do people link
from C to assembler to begin with? To do things they cannot do in pure C! I
would say that addressing some data above the bar is a valid case of that.
Charles
-----Original Message-----
Behalf Of Peter Hunkeler
Sent: Monday, August 28, 2017 11:49 PM
Subject: AW: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64
assembler?
Post by Charles Mills
If I had nothing better to do I would open an RFE on that. Even assuming
AMODE 31, how can LE assume that the high halves of the registers are of no
debugging value? 64-bit register arithmetic -- or even using the high halves
of registers as a temporary holding area -- is a valid technique even in the
absence of AMODE 64. The C/C++ compiler itself does so.
Have a look at the "Language Environment Programming Guide for 64-bit
Virtual Addressing Mode" manual, chapter "Chapter 21. Assembler
considerations". It has some description about AMODE 64 assembler. I browsed
it quickly, only. It talks about XPLINK convention to be a prerequisite for
AMODE 64 assembler in a LE supported way. I never did anything with XPLINK,
so I cannot say how much effort this is, but maybe you can change your
assembler code to be LE AMODE 64 compatible.
While your "SDWA hack" seems to work (today), it is cheating, as you said
yourself. May hurt you, or your customer in the future.
--
Peter Hunkeler
--
Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive
***@sas.com (919) 531-5637 Cary, NC 27513

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-08-29 15:33:18 UTC
Permalink
Raw Message
Post by Don Poitras
But you _can_ address data above the bar in "pure" C. Just compile and link
the C code as 64-bit.
​I've no experience, but from what I've read, this is "CPU costly" in that
the 31 bit C is running in a "normal" (non-XPLINK) LE enclave whereas 64
bit C _must_ run in an XPLINK LE enclave. Starting and stopping the XPLINK
LE enclave is "expensive", again from what I've read. Of course, with some
hard work, I think it might be possible to use a CEEPIPI to create and
maintain an XPLINK 64 bit LE enclave and dynamically swap between the LE
enclaves.​
--
Caution! The OP is an hyperpolysyllabicsesquipedalianist and this email may
cause stress to those with hippopotomonstrosesquipedaliophobia.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
B***@T-ONLINE.DE
2017-08-29 15:55:45 UTC
Permalink
Raw Message
some years ago I Had to call a openssl library from Pl/1. the Openssl
library was compiled using XPlink (31 Bit). it worked in the End. the only
Problem was that there Had to be a Interface Module doing a dynamic fetch
on the XPlink object, because static linkage was Not possible. And Posix
(on) was needed. But No Problems with Switching enclaves etc.


------------------------------------------------------------------------
Gesendet mit der Telekom Mail App
<http://www.t-online.de/service/redir/email_app_android_sendmail_footer.htm>



--- Original-Nachricht ---
Von: John McKown
Betreff: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64
assembler?
Datum: 29.08.2017, 17:34 Uhr
Post by Don Poitras
But you _can_ address data above the bar in "pure" C. Just compile and link
the C code as 64-bit.
I've no experience, but from what I've read, this is "CPU costly" in that
the 31 bit C is running in a "normal" (non-XPLINK) LE enclave whereas 64
bit C _must_ run in an XPLINK LE enclave. Starting and stopping the XPLINK
LE enclave is "expensive", again from what I've read. Of course, with some
hard work, I think it might be possible to use a CEEPIPI to create and
maintain an XPLINK 64 bit LE enclave and dynamically swap between the LE
enclaves.

--
Caution! The OP is an hyperpolysyllabicsesquipedalianist and this email may
cause stress to those with hippopotomonstrosesquipedaliophobia.

Maranatha! <><
John McKown

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-08-29 17:01:25 UTC
Permalink
Raw Message
Just compile and link the C code as 64-bit.
That is a HUGE "just." This is tens of thousands of lines of C++ code, many
called library routines, and many linked-in atomic assembler functions. Not
a small "just" at all.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Don Poitras
Sent: Tuesday, August 29, 2017 8:28 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64
assembler?

But you _can_ address data above the bar in "pure" C. Just compile and link
the C code as 64-bit.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-08-28 13:14:47 UTC
Permalink
Raw Message
I can see all 64 bits in the SDWA.
CharlesSent from a mobile; please excuse the brevity.
-------- Original message --------From: Steve Smith <***@GMAIL.COM> Date: 8/28/17 8:47 AM (GMT-05:00) To: IBM-***@LISTSERV.UA.EDU Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?
I can only guess that this particular register dump comes from a
32-bit savearea.  Deliberately masking off the high-halves when
available would be profoundly asinine.  Say it ain't so, LE!

sas

On Sun, Aug 27, 2017 at 5:01 PM, Charles Mills <***@mcn.org> wrote:
...
Post by Charles Mills
LE fails to print the high register halves, for example
GPR0..... ********_000000C6  GPR1..... ********_00000020  GPR2..... ********_FFFFFFFF  GPR3..... ********_00000002
If I had nothing better to do I would open an RFE on that. Even assuming AMODE 31, how can LE assume that the high halves of the registers are of no debugging value? 64-bit register arithmetic -- or even using the high halves of registers as a temporary holding area -- is a valid technique even in the absence of AMODE 64. The C/C++ compiler itself does so.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
B***@T-ONLINE.DE
2017-08-28 13:27:04 UTC
Permalink
Raw Message
it was 2005 ca., when we decided at my Former customer's Site to replace
the four or five different Abend Handling and dump printing Routines by
one. The Input was different, the Output should be the Same. only one of
the Input Variants then Had 32 Bit Registers, all others were alresdy 64.
Of course, we Always showed 64 Bit register contents, when possible.


------------------------------------------------------------------------
Gesendet mit der Telekom Mail App
<http://www.t-online.de/service/redir/email_app_android_sendmail_footer.htm>



--- Original-Nachricht ---
Von: Charles Mills
Betreff: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64
assembler?
Datum: 28.08.2017, 15:15 Uhr
An: IBM-***@LISTSERV.UA.EDU





I can see all 64 bits in the SDWA.
CharlesSent from a mobile; please excuse the brevity.
-------- Original message --------From: Steve Smith <***@GMAIL.COM>
Date: 8/28/17 8:47 AM (GMT-05:00) To: IBM-***@LISTSERV.UA.EDU Subject: Re:
Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?
I can only guess that this particular register dump comes from a
32-bit savearea.  Deliberately masking off the high-halves when
available would be profoundly asinine.  Say it ain't so, LE!

sas

On Sun, Aug 27, 2017 at 5:01 PM, Charles Mills <***@mcn.org>
<http://mcn.org>> ; wrote:
...
Post by Charles Mills
LE fails to print the high register halves, for example
GPR0..... ********_000000C6  GPR1..... ********_00000020  GPR2.....
********_FFFFFFFF  GPR3..... ********_00000002
Post by Charles Mills
If I had nothing better to do I would open an RFE on that. Even assuming
AMODE 31, how can LE assume that the high halves of the registers are of no
debugging value? 64-bit register arithmetic -- or even using the high
halves of registers as a temporary holding area -- is a valid technique
even in the absence of AMODE 64. The C/C++ compiler itself does so.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu <http://listserv.ua.edu> with the
message: INFO IBM-MAIN


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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2017-08-29 12:51:54 UTC
Permalink
Raw Message
I do not pretend to know the answer to the initial question, but when
Charles mentioned updating the SDWA, that seems really problematic to me.

I tried a simple experiment:
-- Mainline sets 2 ESTAEXs
-- Mainline blows up
-- Newest ESTAEX routine gets control and updates the "AMODE 64" bit in
the PSWs of SDWAEC1, SDWAEC2, SDWAPSW16
-- That ESTAEX routine percolates
-- Older ESTAEX routine gets control. It finds the AMODE 64 bits on in all
of those PSWs.

This is what I expected because, for the most part, RTM builds the SDWA
anew for each recovey routine, from a protected copy so that changes made
by one ESTAE routine are not visible to the next (there are likely some
exceptions, but the PSWs are part of the re-build).

I have no explanation for why LE's behavior would change based on setting
of some bit that an ESTAE routine changed, unless that routine is itself
calling LE providing that SDWA. Oherwise, LE would have no idea that you
changed anything.

Probably a stupid question: since running AMODE 64 is pretty much outside
the bounds of 31-bit LE, have you considered protecting your AMODE 64 code
with your own recovery and having that recovery field any problem
appropriately? The ESTAEX SPIEOVERRIDE keyword can be used to make sure
that LE's (E)SPIE does not get control if a program interrupt occurs.

Peter Relson
z/OS Core Technology Design


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-08-29 15:11:29 UTC
Permalink
Raw Message
@Peter, thanks as always.

I had not noticed SPIEOVERRIDE. It would be a better approach than "remember
to turn off SPIE in LE."

There's not many AMODE 64 instructions -- basically load up a 64-bit pointer
and move the data below the bar. I wonder if perhaps FRR would be
appropriate. (Not a question for you; a question for me.)

There's little doubt about the behavior I saw, and in fact, I only set off
bit 31 in the SDWAPSW16, nothing else.

I'm on another problem at the moment but I will repeat the experiments for
sure at some point here.

L R3,SDWAXPAD Load SDWA extension ptrs
L R4,SDWAXEME-SDWAPTRS(,R4) Load ptr to 64-bit regs
USING SDWARC4,R4
*
NI SDWAPSW16+3,X'FE'
*
LR R1,R9 SDWA
SETRP RC=0 Percolate!
*
NOSDWA EQU *
DROP R9,R4
*
RETURN EQU *
LR R14,R8 Restore R14
BR R14 Return

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Tuesday, August 29, 2017 5:51 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64
assembler?

I do not pretend to know the answer to the initial question, but when
Charles mentioned updating the SDWA, that seems really problematic to me.

I tried a simple experiment:
-- Mainline sets 2 ESTAEXs
-- Mainline blows up
-- Newest ESTAEX routine gets control and updates the "AMODE 64" bit in the
PSWs of SDWAEC1, SDWAEC2, SDWAPSW16
-- That ESTAEX routine percolates
-- Older ESTAEX routine gets control. It finds the AMODE 64 bits on in all
of those PSWs.

This is what I expected because, for the most part, RTM builds the SDWA anew
for each recovey routine, from a protected copy so that changes made by one
ESTAE routine are not visible to the next (there are likely some exceptions,
but the PSWs are part of the re-build).

I have no explanation for why LE's behavior would change based on setting of
some bit that an ESTAE routine changed, unless that routine is itself
calling LE providing that SDWA. Oherwise, LE would have no idea that you
changed anything.

Probably a stupid question: since running AMODE 64 is pretty much outside
the bounds of 31-bit LE, have you considered protecting your AMODE 64 code
with your own recovery and having that recovery field any problem
appropriately? The ESTAEX SPIEOVERRIDE keyword can be used to make sure that
LE's (E)SPIE does not get control if a program interrupt occurs.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2017-08-29 16:37:59 UTC
Permalink
Raw Message
Answering anyway, even if *I'm* neither you or me :-): FRR is
generally only appropriate when you have no other choice. But I've
recently implemented an ARR, which is purportedly a higher-performing
alternative to ESTAE[X]. The IEAARR macro invokes the protected
routine, so it replaces your CALL/LINK/whatever. It fit in nicely for
my situation.

The IEAARR macro itself is ridiculous. Just grimace and bear it.

sas
Post by Charles Mills
@Peter, thanks as always.
.... I wonder if perhaps FRR would be
appropriate. (Not a question for you; a question for me.)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-08-29 17:01:09 UTC
Permalink
Raw Message
On some further review, a separate "AMODE 64 ESTAE" won't do anything for me
(unless I am missing something). My existing ESTAE is working fine.

The issue at hand is "how do I get C/C++ to trigger a Signal routine." For
you assembler folks, a Signal routine is roughly equivalent to a retry
routine. In fact, I guess it is C's implementation of what under the covers
is LE's retry routine.

My business logic is all in C++ (and man am I happy with that! No more "oh
crap, I forgot to clear R2" type problems. But I digress). The problem at
hand is "I just S0C4'ed. How do I get into my cleanup logic and clean
everything up, write the appropriate diagnostics, etc.?" The answer should
be "by driving my Signal routine."

So what is failing is not "my" ESTAE, but the percolation to LE's ESTAE, or
rather, what happens after percolation in LE's recovery routine. I am not a
mind reader, but my guess is that LE is saying "the ABEND took place in
AMODE 64 code. That is not my problem. Don't drive the retry (Signal)
routine; percolate to MVS." That is the problem I want to solve.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Tuesday, August 29, 2017 8:13 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64
assembler?

@Peter, thanks as always.

I had not noticed SPIEOVERRIDE. It would be a better approach than "remember
to turn off SPIE in LE."

There's not many AMODE 64 instructions -- basically load up a 64-bit pointer
and move the data below the bar. I wonder if perhaps FRR would be
appropriate. (Not a question for you; a question for me.)

There's little doubt about the behavior I saw, and in fact, I only set off
bit 31 in the SDWAPSW16, nothing else.

I'm on another problem at the moment but I will repeat the experiments for
sure at some point here.

L R3,SDWAXPAD Load SDWA extension ptrs
L R4,SDWAXEME-SDWAPTRS(,R4) Load ptr to 64-bit regs
USING SDWARC4,R4
*
NI SDWAPSW16+3,X'FE'
*
LR R1,R9 SDWA
SETRP RC=0 Percolate!
*
NOSDWA EQU *
DROP R9,R4
*
RETURN EQU *
LR R14,R8 Restore R14
BR R14 Return

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Tuesday, August 29, 2017 5:51 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64
assembler?

I do not pretend to know the answer to the initial question, but when
Charles mentioned updating the SDWA, that seems really problematic to me.

I tried a simple experiment:
-- Mainline sets 2 ESTAEXs
-- Mainline blows up
-- Newest ESTAEX routine gets control and updates the "AMODE 64" bit in the
PSWs of SDWAEC1, SDWAEC2, SDWAPSW16
-- That ESTAEX routine percolates
-- Older ESTAEX routine gets control. It finds the AMODE 64 bits on in all
of those PSWs.

This is what I expected because, for the most part, RTM builds the SDWA anew
for each recovey routine, from a protected copy so that changes made by one
ESTAE routine are not visible to the next (there are likely some exceptions,
but the PSWs are part of the re-build).

I have no explanation for why LE's behavior would change based on setting of
some bit that an ESTAE routine changed, unless that routine is itself
calling LE providing that SDWA. Oherwise, LE would have no idea that you
changed anything.

Probably a stupid question: since running AMODE 64 is pretty much outside
the bounds of 31-bit LE, have you considered protecting your AMODE 64 code
with your own recovery and having that recovery field any problem
appropriately? The ESTAEX SPIEOVERRIDE keyword can be used to make sure that
LE's (E)SPIE does not get control if a program interrupt occurs.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Bernd Oppolzer
2017-08-29 21:43:04 UTC
Permalink
Raw Message
Would the following approach help?

From C/C++, you call an ASSEMBLER submodule, which ATTACHes a subtask
and waits for its completion.

The subtask does all the 64 bit AMODE switching (and return), and
establishes
an ESTAE exit (or other technique) to handle errors that occur inside
the subtask.
If errors occurs, you return information about the error to the C/C++
main task
(normal return, not percolate), which then can signal the error and
activate
the LE error handling, as usual, so you can do your garbage collection
tasks etc.

Kind regards

Bernd
Post by Charles Mills
On some further review, a separate "AMODE 64 ESTAE" won't do anything for me
(unless I am missing something). My existing ESTAE is working fine.
The issue at hand is "how do I get C/C++ to trigger a Signal routine." For
you assembler folks, a Signal routine is roughly equivalent to a retry
routine. In fact, I guess it is C's implementation of what under the covers
is LE's retry routine.
My business logic is all in C++ (and man am I happy with that! No more "oh
crap, I forgot to clear R2" type problems. But I digress). The problem at
hand is "I just S0C4'ed. How do I get into my cleanup logic and clean
everything up, write the appropriate diagnostics, etc.?" The answer should
be "by driving my Signal routine."
So what is failing is not "my" ESTAE, but the percolation to LE's ESTAE, or
rather, what happens after percolation in LE's recovery routine. I am not a
mind reader, but my guess is that LE is saying "the ABEND took place in
AMODE 64 code. That is not my problem. Don't drive the retry (Signal)
routine; percolate to MVS." That is the problem I want to solve.
Charles
-----Original Message-----
Behalf Of Charles Mills
Sent: Tuesday, August 29, 2017 8:13 AM
Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64
assembler?
@Peter, thanks as always.
I had not noticed SPIEOVERRIDE. It would be a better approach than "remember
to turn off SPIE in LE."
There's not many AMODE 64 instructions -- basically load up a 64-bit pointer
and move the data below the bar. I wonder if perhaps FRR would be
appropriate. (Not a question for you; a question for me.)
There's little doubt about the behavior I saw, and in fact, I only set off
bit 31 in the SDWAPSW16, nothing else.
I'm on another problem at the moment but I will repeat the experiments for
sure at some point here.
L R3,SDWAXPAD Load SDWA extension ptrs
L R4,SDWAXEME-SDWAPTRS(,R4) Load ptr to 64-bit regs
USING SDWARC4,R4
*
NI SDWAPSW16+3,X'FE'
*
LR R1,R9 SDWA
SETRP RC=0 Percolate!
*
NOSDWA EQU *
DROP R9,R4
*
RETURN EQU *
LR R14,R8 Restore R14
BR R14 Return
Charles
-----Original Message-----
Behalf Of Peter Relson
Sent: Tuesday, August 29, 2017 5:51 AM
Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64
assembler?
I do not pretend to know the answer to the initial question, but when
Charles mentioned updating the SDWA, that seems really problematic to me.
-- Mainline sets 2 ESTAEXs
-- Mainline blows up
-- Newest ESTAEX routine gets control and updates the "AMODE 64" bit in the
PSWs of SDWAEC1, SDWAEC2, SDWAPSW16
-- That ESTAEX routine percolates
-- Older ESTAEX routine gets control. It finds the AMODE 64 bits on in all
of those PSWs.
This is what I expected because, for the most part, RTM builds the SDWA anew
for each recovey routine, from a protected copy so that changes made by one
ESTAE routine are not visible to the next (there are likely some exceptions,
but the PSWs are part of the re-build).
I have no explanation for why LE's behavior would change based on setting of
some bit that an ESTAE routine changed, unless that routine is itself
calling LE providing that SDWA. Oherwise, LE would have no idea that you
changed anything.
Probably a stupid question: since running AMODE 64 is pretty much outside
the bounds of 31-bit LE, have you considered protecting your AMODE 64 code
with your own recovery and having that recovery field any problem
appropriately? The ESTAEX SPIEOVERRIDE keyword can be used to make sure that
LE's (E)SPIE does not get control if a program interrupt occurs.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Gord Tomlin
2017-08-29 22:15:17 UTC
Permalink
Raw Message
Post by Bernd Oppolzer
Would the following approach help?
From C/C++, you call an ASSEMBLER submodule, which ATTACHes a subtask
and waits for its completion.
The subtask does all the 64 bit AMODE switching (and return), and
establishes
an ESTAE exit (or other technique) to handle errors that occur inside
the subtask.
If errors occurs, you return information about the error to the C/C++
main task
(normal return, not percolate), which then can signal the error and
activate
the LE error handling, as usual, so you can do your garbage collection
tasks etc.
Kind regards
Bernd
I think an approach like this would only be reasonable of the volume of
calls to the 64-bit code are very infrequent. If the 64-bit routine(s)
is/are called a lot, the overhead would be prohibitive.

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-08-29 22:31:28 UTC
Permalink
Raw Message
Agreed.

An easier approach by far would be to have my recovery routine retry to a routine that issued a distinct user ABEND in AMODE 31, perhaps first copying the SDWA to some storage that could subsequently be displayed.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Gord Tomlin
Sent: Tuesday, August 29, 2017 3:16 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?
Post by Bernd Oppolzer
Would the following approach help?
From C/C++, you call an ASSEMBLER submodule, which ATTACHes a subtask
and waits for its completion.
The subtask does all the 64 bit AMODE switching (and return), and
establishes an ESTAE exit (or other technique) to handle errors that
occur inside the subtask.
If errors occurs, you return information about the error to the C/C++
main task (normal return, not percolate), which then can signal the
error and activate the LE error handling, as usual, so you can do your
garbage collection tasks etc.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Hunkeler
2017-08-30 06:42:15 UTC
Permalink
Raw Message
Post by Charles Mills
An easier approach by far would be to have my recovery routine retry to a routine that issued a distinct user ABEND in AMODE 31, perhaps first copying the SDWA to some storage that could subsequently be displayed.
I was about to propose something the like. Handle all the AMDOE 64 stuff in you assembler code, i.e. let your ESTAE retry. Your retry routine saves all the information your signal handler must know, goes back to AMODE 31, deregisters your ESTAE and ABENDs with some user abend code. LE's ESTAE will catch up and your signal handler should finally be driven.
--
Peter Hunkeler

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-08-30 13:21:03 UTC
Permalink
Raw Message
This problem is still in flux and I have other priorities at this instant.

But having kinda sorta said @Peter was wrong I wanted to get back here and
say there is something going on that I do not understand.

Yes, LE worked as desired when I set off the AMODE 64 bit as I wrote the
below. But I also had it work as desired in one test yesterday when I did
*not* set off that bit. So yes, perhaps setting off that bit is irrelevant
and the success was coincidental.

More research required. Something (in my code?) is having unintended side
effects. Pretty simple code and hard to see what might be wrong, but that's
what makes programming fun, right?

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Tuesday, August 29, 2017 8:13 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64
assembler?

@Peter, thanks as always.

I had not noticed SPIEOVERRIDE. It would be a better approach than "remember
to turn off SPIE in LE."

There's not many AMODE 64 instructions -- basically load up a 64-bit pointer
and move the data below the bar. I wonder if perhaps FRR would be
appropriate. (Not a question for you; a question for me.)

There's little doubt about the behavior I saw, and in fact, I only set off
bit 31 in the SDWAPSW16, nothing else.

I'm on another problem at the moment but I will repeat the experiments for
sure at some point here.

L R3,SDWAXPAD Load SDWA extension ptrs
L R4,SDWAXEME-SDWAPTRS(,R4) Load ptr to 64-bit regs
USING SDWARC4,R4
*
NI SDWAPSW16+3,X'FE'
*
LR R1,R9 SDWA
SETRP RC=0 Percolate!
*
NOSDWA EQU *
DROP R9,R4
*
RETURN EQU *
LR R14,R8 Restore R14
BR R14 Return

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-08-30 13:44:48 UTC
Permalink
Raw Message
Post by Charles Mills
This problem is still in flux and I have other priorities at this instant.
say there is something going on that I do not understand.
Yes, LE worked as desired when I set off the AMODE 64 bit as I wrote the
below. But I also had it work as desired in one test yesterday when I did
*not* set off that bit. So yes, perhaps setting off that bit is irrelevant
and the success was coincidental.
More research required. Something (in my code?) is having unintended side
effects. Pretty simple code and hard to see what might be wrong, but that's
what makes programming fun, right?
​Coming in out of far left field (as is my wont), the original message
mentioned S0C4 & S0C1 abends in your AMODE 64. Given that the best
exception is no exception, for the S0C4 case, perhaps validating your
addresses via VSMLOC could avoid the S0C4 in the first place. If the S0C4
is an true PIC 4 (attempt to store where you aren't allowed), perhaps
checking the key using IVSK would be helpful as well.​
Post by Charles Mills
Charles
--
Caution! The OP is an hyperpolysyllabicsesquipedalianist and this email may
cause stress to those with hippopotomonstrosesquipedaliophobia.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-08-30 14:01:54 UTC
Permalink
Raw Message
Well, yeah. The fix for the S0C4? Stop accessing invalid storage! :-)

It is super-complex, super-high-performance code. Very tricky and difficult. FWIW, it is a read-type access.

There are no S0C1's except in my intentional test code -- I just mentioned S0C1 as an example of an exception.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of John McKown
Sent: Wednesday, August 30, 2017 6:46 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?
Post by Charles Mills
This problem is still in flux and I have other priorities at this instant.
and say there is something going on that I do not understand.
the below. But I also had it work as desired in one test yesterday
when I did
*not* set off that bit. So yes, perhaps setting off that bit is
irrelevant and the success was coincidental.
More research required. Something (in my code?) is having unintended
side effects. Pretty simple code and hard to see what might be wrong,
but that's what makes programming fun, right?
​Coming in out of far left field (as is my wont), the original message mentioned S0C4 & S0C1 abends in your AMODE 64. Given that the best exception is no exception, for the S0C4 case, perhaps validating your addresses via VSMLOC could avoid the S0C4 in the first place. If the S0C4 is an true PIC 4 (attempt to store where you aren't allowed), perhaps checking the key using IVSK would be helpful as well.​

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2017-08-29 14:30:39 UTC
Permalink
Raw Message
The ESTAEX SPIEOVERRIDE keyword ...
That's a new one on me. Thanks, Peter! Looks like it was introduced
with z/OS 2.12. Requires APF authorization though....
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-08-29 15:12:23 UTC
Permalink
Raw Message
z/OS 2.12? I missed that too. I am really falling behind here.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Tom Marchant
Sent: Tuesday, August 29, 2017 7:32 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?
The ESTAEX SPIEOVERRIDE keyword ...
That's a new one on me. Thanks, Peter! Looks like it was introduced with z/OS 2.12. Requires APF authorization though....

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2017-08-29 15:19:54 UTC
Permalink
Raw Message
Post by Charles Mills
z/OS 2.12? I missed that too. I am really falling behind here.
ROFL. I meant z/OS 1.12. Thanks for pointing out my error.
--
Tom Marchant
Post by Charles Mills
-----Original Message-----
Sent: Tuesday, August 29, 2017 7:32 AM
Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?
The ESTAEX SPIEOVERRIDE keyword ...
That's a new one on me. Thanks, Peter! Looks like it was introduced with z/OS 2.12. Requires APF authorization though....
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2017-08-30 13:31:56 UTC
Permalink
Raw Message
Post by Steve Smith
The IEAARR macro itself is ridiculous.
OK, I'll bite. In what way(s)?

Peter Relson
z/OS Core Technology Design


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2017-08-30 15:47:06 UTC
Permalink
Raw Message
I realized that my post was missing some important details about the
scenario. See "add:" below.

<snip>
I tried a simple experiment:
-- Mainline sets 2 ESTAEXs
-- Mainline blows up <add: in AMODE 64>
-- Newest ESTAEX routine gets control and updates the "AMODE 64" bit in
the PSWs of SDWAEC1, SDWAEC2, SDWAPSW16 <add: to turn the bit *off*>
-- That ESTAEX routine percolates
-- Older ESTAEX routine gets control. It finds the AMODE 64 bits on in all

of those PSWs.
</snip>

Regarding SpieOverride, we are considering changing that option not to
require authorization.

Note that you can do this yourself:
You can set a "blocking" ESPIE -- ESPIE with no program interrupts
identified.
Then, when you're done, issue ESPIE RESET.

As long as these operations don't require authorization (I don't think
they do but I'm not positive), there's little reason that doing the same
thing for an ESTAEX should require authorization.

Peter Relson
z/OS Core Technology Design


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