Peter Relson wrote:
Yes, you are misreading the dump. Not that it's obvious...
Thanks for that explanation! Makes perfect sense - I should have
thought about it myself :-)
My guess is that my earlier caution is what came to pass. You did not show
the time of error regs. You should have.
I was mistaken about what IEA995I shows. It shows the 128-byte PSWE only
when the address is >= 2G. Thus the very fact that the display is of a
64-bit PSW confirms that the address is below 2G. The scrunched PSW has
bits 0-32 of the PSWE with bit 12 on (bits 31 and 32 are both on for AMODE
64
Yes, you are misreading the dump. Not that it's obvious...
You got an 0C2. That is a privileged operation exception. And you got it
on the PC instruction. The AMODE 31 bit on in the address relates to
scrunching a 128-bit PSWE into a 64-bit PSW. SYSABEND and SYSUDUMP
basically do not support 64
The critical part of the dump is the trace table from the ESTAEX thru the
abend.
On Wed, 25 Mar 2020 00:02:59 -0400 Thomas David Rivers
wrote:
:>Peter Relson wrote:
:>
:>>
:>>What it _looks_ like from the dump is that ESTAEX is invoked
:>>(via PC - this is just problem state) and on return, the
Peter Relson wrote:
What it _looks_ like from the dump is that ESTAEX is invoked
(via PC - this is just problem state) and on return, the address
in the PSW has the AMODE bit set - but we are in AMODE 64,
so now my PSW address is pointing to the wrong place.
Some day, maybe I'll start readin
Ed Jaffe wrote:
On 3/23/2020 2:15 AM, Thomas David Rivers wrote:
I think I've run into an interesting problem with ESTAEX
when it is invoked in AMODE 64 without SYSTATE AMODE=64
set at assembly time.
That is, this is code that could potentially run in either AMODE 31
or AMODE 64... so it's no
I think that snip is just a misunderstanding.
There are two AMODE bits in the PSW, and in the real 128-bit PSW, neither
is in the address part. It doesn't work the way general registers do when
you switch AMODE without cleaning up addresses in registers (which involves
clearing the top 33 bits,
What it _looks_ like from the dump is that ESTAEX is invoked
(via PC - this is just problem state) and on return, the address
in the PSW has the AMODE bit set - but we are in AMODE 64,
so now my PSW address is pointing to the wrong place.
Some day, maybe I'll start reading these initial posts m
What services, IBM or ISV, nowadays can *not* be invoked:
o In AMODE 64?
o With parameters above-the-bar?
o Called from an address above-the-bar?
Surely the audience and OP know the answers to these question for IBM
services
-- most
-- almost all
-- even closer to all.
when can programmers fo
On Tue, 24 Mar 2020 16:47:18 -0700 Ed Jaffe
wrote:
:>On 3/24/2020 2:02 PM, Binyamin Dissen wrote:
:>> PC invoked? - pretty much anything. It really annoyed me that IBM trumpeted
:>> support for 64 bit callers for many services when the hardware did all the
:>> work.
:>Not true. In order for a se
On 3/24/2020 2:02 PM, Binyamin Dissen wrote:
PC invoked? - pretty much anything. It really annoyed me that IBM trumpeted
support for 64 bit callers for many services when the hardware did all the
work.
Not true. In order for a service to officially support 64-bit callers,
IBM must assign peopl
On Tue, 24 Mar 2020 11:17:36 -0500 Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
:>On Mon, 23 Mar 2020 05:15:15 -0400, Thomas David Rivers wrote:
:>>I think I've run into an interesting problem with ESTAEX
:>>when it is invoked in AMODE 64 without SYSTATE AMODE=64
:>>set
ect: Re: Problems with ESTAEX invoked in AMODE 64 when assembled without
SYSTATE AMODE=64
On Mon, 23 Mar 2020 05:15:15 -0400, Thomas David Rivers wrote:
>I think I've run into an interesting problem with ESTAEX
>when it is invoked in AMODE 64 without SYSTATE AMODE=64
>set at assemb
On Mon, 23 Mar 2020 05:15:15 -0400, Thomas David Rivers wrote:
>I think I've run into an interesting problem with ESTAEX
>when it is invoked in AMODE 64 without SYSTATE AMODE=64
>set at assembly time.
>
What services, IBM or ISV, nowadays can *not* be invoked:
o In AMODE 64?
o With parameters abo
On 3/23/2020 2:15 AM, Thomas David Rivers wrote:
I think I've run into an interesting problem with ESTAEX
when it is invoked in AMODE 64 without SYSTATE AMODE=64
set at assembly time.
That is, this is code that could potentially run in either AMODE 31
or AMODE 64... so it's not assembled with SY
I would question this.
Why not post the section from the system trace table showing this?
On Mon, 23 Mar 2020 05:15:15 -0400 Thomas David Rivers
wrote:
:>I think I've run into an interesting problem with ESTAEX
:>when it is invoked in AMODE 64 without SYSTATE AMODE=64
:>set at assembly time.
:>
Really? You violate interface requirements and then worry about problems
that ensue?
You are supposed to issue SYSSTATE AMODE64=YES to indicate that you are
AMODE 64 if invoking z/OS macros. Period. Is this new news to anyone? It
has been this way ever since AMODE64 was supported in any fashio
Well at the top of that page it says:
The type of ESTAE routine, that is, ESTAE or ESTAEX affects the AMODE of
the recovery routine as follows. For recovery routines defined through the:
- ESTAE macro, at the time of entry to the recovery routine, the AMODE
will be the same as at the time o
Joe Monk wrote:
"When you run in AMODE 64 (as indicated by specifying AMODE64=YES through
the SYSSTATE macro) and invoke ESTAEX, your ESTAEX routine will get control
in AMODE 64."
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieaa200/iea3a2_Description3.htm
So looks
Joe Monk wrote:
"When you run in AMODE 64 (as indicated by specifying AMODE64=YES through
the SYSSTATE macro) and invoke ESTAEX, your ESTAEX routine will get control
in AMODE 64."
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieaa200/iea3a2_Description3.htm
So looks
There is no reason for code that can run either way. If it needs to be
able to run AMODE 64, make sure it always does. It will save a lot of
grief.
sas
On Mon, Mar 23, 2020 at 6:28 PM Charles Mills wrote:
> SYSSTATE has never entirely "felt right" to me. For some things -- like
> ARCH -- it m
al Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Joe Monk
Sent: Monday, March 23, 2020 2:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Problems with ESTAEX invoked in AMODE 64 when assembled without
SYSTATE AMODE=64
"When you run in AMODE 64
"When you run in AMODE 64 (as indicated by specifying AMODE64=YES through
the SYSSTATE macro) and invoke ESTAEX, your ESTAEX routine will get control
in AMODE 64."
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieaa200/iea3a2_Description3.htm
So looks like you have to s
I think I've run into an interesting problem with ESTAEX
when it is invoked in AMODE 64 without SYSTATE AMODE=64
set at assembly time.
That is, this is code that could potentially run in either AMODE 31
or AMODE 64... so it's not assembled with SYSTATE AMODE=64.
What it _looks_ like from the dum
24 matches
Mail list logo