Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Peter Relson]

I realized that my post was missing some important details about the 
scenario. See "add:" below.


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.


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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Charles Mills]

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-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Wednesday, August 30, 2017 6:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

On Wed, Aug 30, 2017 at 8:22 AM, Charles Mills  wrote:

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

​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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[John McKown]

On Wed, Aug 30, 2017 at 8:22 AM, Charles Mills  wrote:

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

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



>
> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Peter Relson]

>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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Charles Mills]

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-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Tuesday, August 29, 2017 8:13 AM
To: IBM-MAIN@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
*  
 NISDWAPSW16+3,X'FE'
*
 LRR1,R9   SDWA
 SETRP RC=0Percolate!
*
NOSDWA   EQU   *
 DROP  R9,R4 
* 
RETURN   EQU   *
 LRR14,R8  Restore R14
 BRR14 Return

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

AW: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Peter Hunkeler]

>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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Charles Mills]

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-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gord Tomlin
Sent: Tuesday, August 29, 2017 3:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

On 2017-08-29 17:44, Bernd Oppolzer wrote:
> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Gord Tomlin]

On 2017-08-29 17:44, Bernd Oppolzer wrote:

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[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


Am 29.08.2017 um 19:01 schrieb 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-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Tuesday, August 29, 2017 8:13 AM
To: IBM-MAIN@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
*
  NISDWAPSW16+3,X'FE'
*
  LRR1,R9   SDWA
  SETRP RC=0Percolate!
*
NOSDWA   EQU   *
  DROP  R9,R4
*
RETURN   EQU   *
  LRR14,R8  Restore R14
  BRR14 Return

Charles

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

[Charles Mills]

> 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-MAIN@LISTSERV.UA.EDU] On
Behalf Of Don Poitras
Sent: Tuesday, August 29, 2017 8:28 AM
To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[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-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Tuesday, August 29, 2017 8:13 AM
To: IBM-MAIN@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
*  
 NISDWAPSW16+3,X'FE'
*
 LRR1,R9   SDWA
 SETRP RC=0Percolate!
*
NOSDWA   EQU   *
 DROP  R9,R4 
* 
RETURN   EQU   *
 LRR14,R8  Restore R14
 BRR14 Return

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Tuesday, August 29, 2017 5:51 AM
To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Steve Smith]

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

On Tue, Aug 29, 2017 at 11:12 AM, Charles Mills  wrote:
> @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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[bernd.oppol...@t-online.de]

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




--- 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
An: IBM-MAIN@LISTSERV.UA.EDU





On Tue, Aug 29, 2017 at 10:28 AM, Don Poitras 
> ; wrote:

> 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 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: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[John McKown]

On Tue, Aug 29, 2017 at 10:28 AM, Don Poitras  wrote:

> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Don Poitras]

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

In article <007a01d320d9$fd9133a0$f8b39ae0$@mcn.org> you wrote:
> 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-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Hunkeler
> Sent: Monday, August 28, 2017 11:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: AW: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64
> assembler?

> >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...@sas.com   (919) 531-5637Cary, NC 27513

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

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Tom Marchant]

On Tue, 29 Aug 2017 08:13:33 -0700, Charles Mills wrote:

>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
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Tom Marchant
>Sent: Tuesday, August 29, 2017 7:32 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?
>
>On Tue, 29 Aug 2017 08:50:42 -0400, Peter Relson wrote:
>
>>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 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: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[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-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: Monday, August 28, 2017 11:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64
assembler?

>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 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: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Charles Mills]

z/OS 2.12? I missed that too. I am really falling behind here.

Charles


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

On Tue, 29 Aug 2017 08:50:42 -0400, Peter Relson wrote:

>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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Charles Mills]

@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
*  
 NISDWAPSW16+3,X'FE'
*
 LRR1,R9   SDWA
 SETRP RC=0Percolate!
*
NOSDWA   EQU   *
 DROP  R9,R4 
* 
RETURN   EQU   *
 LRR14,R8  Restore R14
 BRR14 Return

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Tuesday, August 29, 2017 5:51 AM
To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Tom Marchant]

On Tue, 29 Aug 2017 08:50:42 -0400, Peter Relson wrote:

>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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Peter Relson]

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Peter Hunkeler]

>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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Peter Hunkeler]

>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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[bernd.oppol...@t-online.de]

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




--- 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-MAIN@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  
Date: 8/28/17 8:47 AM (GMT-05:00) To: IBM-MAIN@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 
> ; wrote:
...
>
> LE fails to print the high register halves, for example
>
> GPR0. _00C6  GPR1. _0020  GPR2. 
_  GPR3. _0002
>
> 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 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 / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Charles Mills]

I can see all 64 bits in the SDWA.
CharlesSent from a mobile; please excuse the brevity.
 Original message From: Steve Smith  Date: 
8/28/17  8:47 AM  (GMT-05:00) To: IBM-MAIN@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  wrote:
...
>
> LE fails to print the high register halves, for example
>
> GPR0. _00C6  GPR1. _0020  GPR2. 
> _  GPR3. _0002
>
> 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 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: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Steve Smith]

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  wrote:
...
>
> LE fails to print the high register halves, for example
>
> GPR0. _00C6  GPR1. _0020  GPR2. 
> _  GPR3. _0002
>
> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Charles Mills]

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. _00C6  GPR1. _0020  GPR2. 
_  GPR3. _0002

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-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bernd Oppolzer
Sent: Sunday, August 27, 2017 4:24 PM
To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Bernd Oppolzer]

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


Am 27.08.2017 um 22:15 schrieb 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[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-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Sunday, August 27, 2017 3:45 PM
To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[Bernd Oppolzer]

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


Am 27.08.2017 um 21:44 schrieb 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-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of bernd.oppol...@t-online.de
Sent: Sunday, August 27, 2017 2:38 PM
To: IBM-MAIN@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 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: Can AMODE 31 C/C++ get a signal on a S0C1/4 in AMODE 64 assembler?

[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-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of bernd.oppol...@t-online.de
Sent: Sunday, August 27, 2017 2:38 PM
To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN