Re: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64
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. You will probably see that the high half of reg 14 is not zero. And therefore the part of the expansion that picks up the PC number did not fetch from the intended location (because you did not tell the expansion that you are, or even might be, AMODE 64). And if you looked at reg 14, it probably was not the PC number for ESTAEX. Once the PC number was fetched the PC was issued and apparently it's a PC that requires authorization that you do not have. Hence PIC 2. Hmm - you seem to be on the best path for sure - but every dump of the registers is telling me that the high-halves are all zero. *but* What is more important is this: GPRS AT TIME OF ERROR 1JOB AOUT STEP AOUTTIME 170714 DATE 20083 ID = 000 PAGE 0023 0-3 1F9A4010 1F9A42B0 1F9A4010 4-7 01700D58 1F9A4090 1F90A7A8 1F98D160 8-11 1F9A4010 1F9A4090 FF0F 01602080 12-15 1F90B080 1F9A4090 1F9A4090 Somehow R14 is zero - which likely doesn't work too well either :-) Looking at the expansion of ESTAEX - perhaps (somehow) R14 got some bits in the high-half (as you suggest) before the ESTAEX, then this expanded code wouldn't work in AMODE 64 (seems like you'd bump into an exception before you got to the PC - but maybe this is just *really* lucky?) So - if R14 has bits in the high-half, and we're in AMODE 64 and we have: 16D8 1813 2863+ LR 1,3 LOAD PARAMETER REG 1 02-IHBIN 16DA 5061 0010 0010 2864+ ST 6,16(1,0) STORE USER EXIT ADDRESS @P3C 01-ESTAE 16DE 94DF 1000 00DF 2865+ NI 0(1),223TURN OFF FLAG BITS 01-ESTAE 16E2 9604 1000 0004 2866+ OI 0(1),4 FLAGS FOR ESTAEX@L1C 01-ESTAE 16E6 5020 1008 0008 2867+ ST 2,8(0,1)MODIFY LIST - PARAM ADDR 01-ESTAE 16EA 9201 1003 0003 0001 2868+ MVI 3(1),1SET VERSION NUMBER 01-ESTAE 16EE 4100 2869+ LA 0,0(0,0)CREATE & PARMLST EQ 0 @L1C 01-ESTAE 16F2 58E0 0010 0010 2870+ L 14,16(0,0) GET CVT ADDRESS 01-ESTAE 16F6 58EE 0304 0304 2871+ L 14,772(14,0)GET SFT ADDRESS 01-ESTAE 16FA 58EE 00B0 00B0 2872+ L 14,176(14,0)GET LX/EX01-ESTAE 16FE B218 E000 2873+ PC 0(14) ISSUE PC 01-ESTAE Then - thing could easily go *very* wrong... But, each of the L's of R14 isn't going to change the bits in the high-half... and R14 has zero in the high-half at the time of the error... or - maybe the dump just isn't telling me that something else is in there. Thanks for the suggestion! I'll give clearing R14 a try! - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64
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) and bits 97-127 of the PSWE. This is the format needed if this 8-byte field were to be used for LPSW (if bit 32 were off but bit 31 on, LPSW would result in a specification exception). Here's an example: SY1 IEA995I SYMPTOM DUMP OUTPUT SYSTEM COMPLETION CODE=0C2 REASON CODE=0002 TIME=11.42.55 SEQ=00019 CPU= ASID=0034 PSW AT TIME OF ERROR 078D2001 88F00092 ILC 4 INTC 02 ACTIVE MODULE ADDRESS=_08F0 OFFSET=0092 NAME=TEST DATA AT PSW 08F0008C - 0950ACFC 10008000 1000A718 AR/GR 0: /_0064 1: /_0950 2: /_08F0008A 3: /_08F00062 4: /_005ECD40 5: /_005FED90 6: /_005DBFC8 7: /_00FCAE80 8: /_005FEF28 9: /_005F84A8 A: /_01D9EF00 B: /_0001 C: /_08F00138 D: /_08F01000 E: /_00FD88D9 F: /_08F0008A END OF SYMPTOM DUMP 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: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE 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-bit storage. Never have, likely never will. That happens to translate into this sort of PSW showing up. If you had showed the IEA995I SYMPTOM DUMP message, it would have had more info (a 128-bit PSWE) and been correct. The AMODE 64 128-bit PSWE at time of error would have been something like 07850001 8000 0xxx Both the AMODE 64 and AMODE 31 bits are on (as is architecturally correct). Scrunching that to a 64-bit PSW has this characteristic. 07850001 8xxx If the address was truly above 2G, then the scrunched PSW would have shown this by the low bit being on (architecturally incorrect for a PSW address). My guess is that my earlier caution is what came to pass. You did not show the time of error regs. You should have. You will probably see that the high half of reg 14 is not zero. And therefore the part of the expansion that picks up the PC number did not fetch from the intended location (because you did not tell the expansion that you are, or even might be, AMODE 64). And if you looked at reg 14, it probably was not the PC number for ESTAEX. Once the PC number was fetched the PC was issued and apparently it's a PC that requires authorization that you do not have. Hence PIC 2. If you must continue down this path, then be sure to clear the high half of reg 14. And, yes, your ESTAE routine will have to dual-path based on the entry AMODE, unless you do dual path the ESTAEX code and have different entries that then join a common path after dealing with the parameter. 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: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=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 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 more carefully. For
:>>whatever reason, I thought you were talking about the ESTAEX routine
:>>getting control at an incorrect place.
:>>
:>>Are you saying that when you issued the PC you were AMODE 64 but you did
:>>not return to the next sequential instruction? There's no realistic chance
:>>of that happening (aside from an abend having occurred). The linkage stack
:>>entry would have had to be overlaid or the PR instruction failed to do
:>>what it is architected to do. One way or another, you are almost
:>>certainly misreading the dump.
:>>
:>>Please provide some data to show that this is true. For example, capture
:>>data to prove that you did issue the ESTAEX as you thought and that you
:>>did not get control at the NSI (such as by having x'' as the NSI and
:>>seeing that you did not get a PIC 1 at that point).
:>>
:>>If you compare the expansions for ESTAEX myESTAEX,PARAM=P you'll see that
:>>the only difference in the expansion between SYSSTATE AMODE64=NO and
:>>SYSSTATE AMODE64=YES lies with how the parameter is processed. AMODE 31
:>>ESTAEX gets control with the 4-byte parameter address and parameter ALET.
:>>AMODE 64 ESTAEX gets control with the 8-byte parameter address. If the
:>>linkage stack entry for the ESTAEX PC indicates that the call was made in
:>>AMODE 64 then the routine will get control in AMODE 64. Otherwise it will
:>>not.
:>>
:>>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
:>>
:>>
:>>
:>Hi Peter!
:>
:> What I seem to be seeing is that I issue the ESTAEX; *without* SYSSTATE
:>AMODE=64,
:>but the program is running AMODE64.
:>
:> When I return back from the PC that results as the expansion of ESTAEX,
:>the PSW
:>is pointing at the next instruction.. but the address in the PSW has the
:>31-bit AMODE
:>set... so - it's the proper address only if you strip that off. The
:>machine has been
:>returned to AMODE 64, but since that AMODE31 bit is set in the PSW
:>address it's
:>a "bad" address...
:>
:> Hope that helps explain things a little more about what I'm seeing...
:>and I understand
:>your point about linkage-stack - that shouldn't be possible. Perhaps
:>the dump
:>is simply showing the wrong PSW address?
:>
:> And - this is just what it looks like from the dump... but - I might
:>just be misreading
:>the dump as you suggest.
:>
:> Here is the start of my SYSUDUMP:
:>
:>1JOB AOUT STEP AOUTTIME 170714 DATE 20083
:>ID = 000
:> CPUID = D301BF6B1090 PAGE 0001
:>0COMPLETION CODE SYSTEM = 0C2 REASON CODE = 0002
:>
:>
:>
:> PSW AT ENTRY TO ABEND 078D1001 9F90B1C2 ILC 04 INTC 0002
:>
:>0PSW MODULE ADDRESS = _1F900880 OFFSET = A942
:>
:> NAME=AOUT
:>
:>
:>which is a 31-bit PSW in the dump?
:>
:>Here's the bytes at 1F90B1A0-1F90B200:
:> 1F90B1A0 10009604 10005020 10089201 1003410058E0 001058EE
:>030458EE 00B0B218 *..o...&...k\*
:> 1F90B1C0 E000B904 00D4E380 C0A40014 B90A0087BF8F8004 4770C15A
:>50F0 D0A8E3F0 *\MT.{u.g..A!..&0}yT0*
:> 1F90B1E0 C0A40014 B90A00F7 A718 5010F004E3F0D0A8 0014D707
:>D088D088 E3D0D080 *{u.7x...&.0.T0}y..P.}h}hT}}.*
:>
:>
:>And - here is the disassembly at starting at 0x1f90b1a0 going for 12
:>instructions:
:>
:>
:> 0x1f90b1a0:1000LPR 0,0
:> 0x1f90b1a2:9604 1000 OI0(1),4
:> 0x1f90b1a6:5020 1008 ST2,8(0,1)
:> 0x1f90b1aa:9201 1003 MVI 3(1),1
:> 0x1f90b1ae:4100 LA0,0(0,0)
:> 0x1f90b1b2:58e0 0010 L 14,16(0,0)
:> 0x1f90b1b6:58ee 0304 L 14,772(14,0)
:> 0x1f90b1ba:58ee 00b0 L 14,176(14,0)
:> 0x1f90b1be:b218 e000 PC0(14)
:> 0x1f90b1c2:b904 00d4 LGR 13,4
:>
:>This is the ASM source:
:>
:> LGR 4,13
:> LGR 13,5
:> LG 6,=AD(ESTAE_EXIT)
:> XGR 1,1 clear upper bits of R1 ESTAEX needs it
:> ESTAEX (6),PARAM=(2),MF=(E,(3))
:> LGR 13,4
:>
:>R5 points to a temp DSA space for the ESTAEX macro (to avoid possible
:>overwrites)
:>and R2 contains the parm to be placed in SDWAPARM.
:>
:>So - it _appears_ (but - I might be reading this wrong) that the PSW address
:>is pointing at the instruction just following the PC for the ESTAEX
Re: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64
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 reading these initial posts more carefully. For
whatever reason, I thought you were talking about the ESTAEX routine
getting control at an incorrect place.
Are you saying that when you issued the PC you were AMODE 64 but you did
not return to the next sequential instruction? There's no realistic chance
of that happening (aside from an abend having occurred). The linkage stack
entry would have had to be overlaid or the PR instruction failed to do
what it is architected to do. One way or another, you are almost
certainly misreading the dump.
Please provide some data to show that this is true. For example, capture
data to prove that you did issue the ESTAEX as you thought and that you
did not get control at the NSI (such as by having x'' as the NSI and
seeing that you did not get a PIC 1 at that point).
If you compare the expansions for ESTAEX myESTAEX,PARAM=P you'll see that
the only difference in the expansion between SYSSTATE AMODE64=NO and
SYSSTATE AMODE64=YES lies with how the parameter is processed. AMODE 31
ESTAEX gets control with the 4-byte parameter address and parameter ALET.
AMODE 64 ESTAEX gets control with the 8-byte parameter address. If the
linkage stack entry for the ESTAEX PC indicates that the call was made in
AMODE 64 then the routine will get control in AMODE 64. Otherwise it will
not.
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
Hi Peter!
What I seem to be seeing is that I issue the ESTAEX; *without* SYSSTATE
AMODE=64,
but the program is running AMODE64.
When I return back from the PC that results as the expansion of ESTAEX,
the PSW
is pointing at the next instruction.. but the address in the PSW has the
31-bit AMODE
set... so - it's the proper address only if you strip that off. The
machine has been
returned to AMODE 64, but since that AMODE31 bit is set in the PSW
address it's
a "bad" address...
Hope that helps explain things a little more about what I'm seeing...
and I understand
your point about linkage-stack - that shouldn't be possible. Perhaps
the dump
is simply showing the wrong PSW address?
And - this is just what it looks like from the dump... but - I might
just be misreading
the dump as you suggest.
Here is the start of my SYSUDUMP:
1JOB AOUT STEP AOUTTIME 170714 DATE 20083
ID = 000
CPUID = D301BF6B1090 PAGE 0001
0COMPLETION CODE SYSTEM = 0C2 REASON CODE = 0002
PSW AT ENTRY TO ABEND 078D1001 9F90B1C2 ILC 04 INTC 0002
0PSW MODULE ADDRESS = _1F900880 OFFSET = A942
NAME=AOUT
which is a 31-bit PSW in the dump?
Here's the bytes at 1F90B1A0-1F90B200:
1F90B1A0 10009604 10005020 10089201 1003410058E0 001058EE
030458EE 00B0B218 *..o...&...k\*
1F90B1C0 E000B904 00D4E380 C0A40014 B90A0087BF8F8004 4770C15A
50F0 D0A8E3F0 *\MT.{u.g..A!..&0}yT0*
1F90B1E0 C0A40014 B90A00F7 A718 5010F004E3F0D0A8 0014D707
D088D088 E3D0D080 *{u.7x...&.0.T0}y..P.}h}hT}}.*
And - here is the disassembly at starting at 0x1f90b1a0 going for 12
instructions:
0x1f90b1a0:1000LPR 0,0
0x1f90b1a2:9604 1000 OI0(1),4
0x1f90b1a6:5020 1008 ST2,8(0,1)
0x1f90b1aa:9201 1003 MVI 3(1),1
0x1f90b1ae:4100 LA0,0(0,0)
0x1f90b1b2:58e0 0010 L 14,16(0,0)
0x1f90b1b6:58ee 0304 L 14,772(14,0)
0x1f90b1ba:58ee 00b0 L 14,176(14,0)
0x1f90b1be:b218 e000 PC0(14)
0x1f90b1c2:b904 00d4 LGR 13,4
This is the ASM source:
LGR 4,13
LGR 13,5
LG 6,=AD(ESTAE_EXIT)
XGR 1,1 clear upper bits of R1 ESTAEX needs it
ESTAEX (6),PARAM=(2),MF=(E,(3))
LGR 13,4
R5 points to a temp DSA space for the ESTAEX macro (to avoid possible
overwrites)
and R2 contains the parm to be placed in SDWAPARM.
So - it _appears_ (but - I might be reading this wrong) that the PSW address
is pointing at the instruction just following the PC for the ESTAEX
(which makes sense)
but it kinda looks like we are not quite right somehow?
Or - maybe it's just how the SYSUDUMP formatted the PSW at the top - and I
just might be really confused - because it looks like a 31-bit PSW but
is in AMODE 64?
If one of those values is incorrect though (like, say, R2) would that
cause the ESTAEX
to blow-up with an 0C2 ?
- Thanks! -
- Dave Rivers -
--
riv...@dignus.comWork: (919)
Re: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64
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 not assembled with SYSTATE AMODE=64. Macro expansions can differ depending on the SYSSTATE settings. It's not safe to ignore that. If the module can legitimately run in either AMODE, I would do something like: |SYSSTATE PUSH Save current SYSSTATE |TAM , Test addressing mode |IF O If 64-bit mode | SYSSTATE AMODE64=YES Tell macros how to expand | ESTAEX ...Establish recovery exit |ELSE ,Else 31-bit mode | SYSSTATE AMODE64=NO Tell macros how to expand | ESTAEX ...Establish recovery exit |ENDIF , EndIf |SYSSTATE POP Restore current SYSSTATE This is a really good idea... There another complication though - the SDWAPARM in the ESTAE EXIT is different when SYSSTATE AMODE64=YES is specified on the ESTAEX macro. So, you might need to do a test in the ESTAE EXIT for AMODE 64 as well. That seems like it would make for a pretty generic routine... many thanks for the idea! - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64
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, not just the high-half). sas On Wed, Mar 25, 2020 at 11:21 AM 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 reading these initial posts more carefully. For > whatever reason, I thought you were talking about the ESTAEX routine > getting control at an incorrect place. > > Are you saying that when you issued the PC you were AMODE 64 but you did > not return to the next sequential instruction? There's no realistic chance > of that happening (aside from an abend having occurred). The linkage stack > entry would have had to be overlaid or the PR instruction failed to do > what it is architected to do. One way or another, you are almost > certainly misreading the dump. > > Please provide some data to show that this is true. For example, capture > data to prove that you did issue the ESTAEX as you thought and that you > did not get control at the NSI (such as by having x'' as the NSI and > seeing that you did not get a PIC 1 at that point). > > If you compare the expansions for ESTAEX myESTAEX,PARAM=P you'll see that > the only difference in the expansion between SYSSTATE AMODE64=NO and > SYSSTATE AMODE64=YES lies with how the parameter is processed. AMODE 31 > ESTAEX gets control with the 4-byte parameter address and parameter ALET. > AMODE 64 ESTAEX gets control with the 8-byte parameter address. If the > linkage stack entry for the ESTAEX PC indicates that the call was made in > AMODE 64 then the routine will get control in AMODE 64. Otherwise it will > not. > > 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 > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64
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 more carefully. For whatever reason, I thought you were talking about the ESTAEX routine getting control at an incorrect place. Are you saying that when you issued the PC you were AMODE 64 but you did not return to the next sequential instruction? There's no realistic chance of that happening (aside from an abend having occurred). The linkage stack entry would have had to be overlaid or the PR instruction failed to do what it is architected to do. One way or another, you are almost certainly misreading the dump. Please provide some data to show that this is true. For example, capture data to prove that you did issue the ESTAEX as you thought and that you did not get control at the NSI (such as by having x'' as the NSI and seeing that you did not get a PIC 1 at that point). If you compare the expansions for ESTAEX myESTAEX,PARAM=P you'll see that the only difference in the expansion between SYSSTATE AMODE64=NO and SYSSTATE AMODE64=YES lies with how the parameter is processed. AMODE 31 ESTAEX gets control with the 4-byte parameter address and parameter ALET. AMODE 64 ESTAEX gets control with the 8-byte parameter address. If the linkage stack entry for the ESTAEX PC indicates that the call was made in AMODE 64 then the routine will get control in AMODE 64. Otherwise it will not. 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: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64
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 forget about 31 and 24? Not in my lifetime. 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: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64
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 service to officially support 64-bit callers, :>IBM must assign people to write test plans and validate every possible :>scenario. At a minimum, the macros and/or the code behind them must :>ensure garbage high-halves are not passed back in return registers. My PC routines supported 64 bit callers on day 1. :>Plus, most 64-bit callers expect to be able to pass parameters from :>their working storage areas (i.e., above the "bar"). Unchanged PCs hat :>are simply validated and nothing more will require special handling by :>64-bit callers to ensure all parameters reside in 31-bit storage. That's :>lame support at best. Full support implies new parameter lists that :>allow 8-byte pointers and such. My comment was that many of the 64bit supported routines did not support 64 bit plists and thus -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64
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 people to write test plans and validate every possible scenario. At a minimum, the macros and/or the code behind them must ensure garbage high-halves are not passed back in return registers. Plus, most 64-bit callers expect to be able to pass parameters from their working storage areas (i.e., above the "bar"). Unchanged PCs hat are simply validated and nothing more will require special handling by 64-bit callers to ensure all parameters reside in 31-bit storage. That's lame support at best. Full support implies new parameter lists that allow 8-byte pointers and such. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64
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 at assembly time. :>What services, IBM or ISV, nowadays can *not* be invoked: :>o In AMODE 64? 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. :>o With parameters above-the-bar? That was the issue. :>o Called from an address above-the-bar? Should not be an issue for PC invoked. :>I.e. when can programmers forget about 31 and 24? Never. :>And there's a residue of data with 31-bit (24?) pointers. Yep. Downward compatibility and all that. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64
>From z/OS Version 2 Release 4 DFSMS Macro Instructions for Data Sets, >SC23-6852-40: "Since none of the macros described in this document support >invocation in 64-bit, AMODE64=YES should not be in effect when calling the >macros described in this book." -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Tuesday, March 24, 2020 12:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 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 assembly time. > 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? I.e. when can programmers forget about 31 and 24? And there's a residue of data with 31-bit (24?) pointers. -- gil -- 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: 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 assembly time. > 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? I.e. when can programmers forget about 31 and 24? And there's a residue of data with 31-bit (24?) pointers. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64
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 SYSTATE AMODE=64. Macro expansions can differ depending on the SYSSTATE settings. It's not safe to ignore that. If the module can legitimately run in either AMODE, I would do something like: | SYSSTATE PUSH Save current SYSSTATE | TAM , Test addressing mode | IF O If 64-bit mode | SYSSTATE AMODE64=YES Tell macros how to expand | ESTAEX ... Establish recovery exit | ELSE , Else 31-bit mode | SYSSTATE AMODE64=NO Tell macros how to expand | ESTAEX ... Establish recovery exit | ENDIF , EndIf | SYSSTATE POP Restore current SYSSTATE -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64
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. :> :>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 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. :> :>Of course - this doesn't work well when AMODE=64 and my :>program gets lost. :> :>This didn't seem to happen with zOS 2.3 - we've recently upgrade :>to zOS 2.4. :> :>Anyone seen anything like that for newer zOS? :> :>I _suppose_ I could always drop to AMODE 31 for invoking ESTAEX, :>but then my ESTAE exit would be in AMODE 31, and I'd prefer for it :>to be in the AMODE at the time ESTAEX is called... :> :>This "feels" unlikely - as the PC is hopefully just going to stack the :>current PSW address for its return... and I'd be very surprised :>of something changed that... but - I thought I would just toss :>that out to see if anyone has an idea. :> :> - Thanks - :>- Dave R. - -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64 (7)
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 fashion (20 years or so). If you violate the requirements of issuing z/OS macros (and calling services) then you get what you get. I have no sympathy. In my opinion, the OP is likely mistaken. There has been no change to the ESTAEX macro (and thus likely no change to its expansion regardless of what SYSSTATE you might or might not have set). I write "likely" only because there could be some underlying macro that changed. I do hope that the OP's code, in AMODE 64 but not indicating so, has made sure that the high half of reg 14 is 0 to avoid unpredictable and unpleasant results. Perhaps the OP could post his exact invocation and (ideally) the expansions in 2.3 and 2.4. As to Charles M's point, AMODE ANY as defined for z/OS does NOT include 64. It is for 24 or 31. Yes you could theoretically write code that runs in either AMODE 31 or 64. That is generally not a great practice if for no other reason than that linkage requirements differ. Capping to AMODE 64 is usually a better approach. As to what do you specify if you do have code that is AMODE 31 or 64? You might have to dual-path, you might specify AMODE64=YES. You certainly don't specify AMODE64=NO. That must be pretty obvious (otherwise you don't get things done like clearing of high halves of registers). SYSSTATE is about assembly-time checking. Differences needed at runtime are left to you. An analog is ASCENV. Although undocumented, a value of "ANY" is allowed which is treated the same as ASCENV=AR -- the expansion is "safe" if you are in AR mode, causing no (or only little) harm if in primary (unnecessarily setting ARs, for example). I was young when I implemented that over 30 years ago and didn't have the influence to say "no" to those who wanted an "ANY" option even if it did nothing unique. 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: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64
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 of invocation of the macro. - *ESTAEX macro, the AMODE will be the same as at the time of invocation of the macro,* unless the macro was invoked in AMODE 24 in which case the recovery routine AMODE will be 31-bit. - The AMODE at the retry point will be the same as the AMODE on entry to the recovery routine. Joe On Mon, Mar 23, 2020 at 6:32 PM Thomas David Rivers wrote: > 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 like you have to specify the SYSSTATE macro in z/os 2.4. > > > >Joe > > > > > I was thinking some more about this - I think you're right that the > sentence there says if you're in AMODE 64 you need to indicate that > with the AMODE64=YES option. > > But - there doesn't seem to be a prohibition from executing the > ESTAEX in AMODE=64 _without_ the AMODE64=YES (which is what > we were doing.) > > There are a couple of ideas floating around in the doc: > >1) - What is the AMODE of the ESTAE EXIT routine? > answer: It is the AMODE at the time of the issuing of the ESTAEX. > >2) - What does the SDWAPARM field look like? > answer: If SYSTATE AMODE=64 is specifed, the SDWAPARM is a > 64-bit > address that points to the value specified on > the PARM parameter > of the ESTAEX. > > IF SYSTATE AMODE=64 is _not_ specified, the > SDWAPARM has > 2 components - the first is a 31-bit pointer to > the value specified > in the PARM paramter of the ESTAEX, the second > is the ALET for > that address. > > Now - when my ESTAEX is complete, the AMODE is properly set to AMODE=64, > it's just that the address in the PSWA now looks like a 31-bit address > (with bit32 > magically set) instead of a "clean" 64-bit address... where before that > didn't happen. > > Seems like returning from ESTAEX shouldn't do that? > > But - then again - you can read that sentence as "if your code runs in > AMODE=64, > you _must_ specify SYSTATE AMODE=64 for the assembly." > > What happens, then, if you specify SYSTATE AMODE=64 but the code is > executing > in AMODE=31 ? > >- Dave R. - > > > > -- > riv...@dignus.comWork: (919) 676-0847 > Get your mainframe programming tools at http://www.dignus.com > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64
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 like you have to specify the SYSSTATE macro in z/os 2.4. Joe I was thinking some more about this - I think you're right that the sentence there says if you're in AMODE 64 you need to indicate that with the AMODE64=YES option. But - there doesn't seem to be a prohibition from executing the ESTAEX in AMODE=64 _without_ the AMODE64=YES (which is what we were doing.) There are a couple of ideas floating around in the doc: 1) - What is the AMODE of the ESTAE EXIT routine? answer: It is the AMODE at the time of the issuing of the ESTAEX. 2) - What does the SDWAPARM field look like? answer: If SYSTATE AMODE=64 is specifed, the SDWAPARM is a 64-bit address that points to the value specified on the PARM parameter of the ESTAEX. IF SYSTATE AMODE=64 is _not_ specified, the SDWAPARM has 2 components - the first is a 31-bit pointer to the value specified in the PARM paramter of the ESTAEX, the second is the ALET for that address. Now - when my ESTAEX is complete, the AMODE is properly set to AMODE=64, it's just that the address in the PSWA now looks like a 31-bit address (with bit32 magically set) instead of a "clean" 64-bit address... where before that didn't happen. Seems like returning from ESTAEX shouldn't do that? But - then again - you can read that sentence as "if your code runs in AMODE=64, you _must_ specify SYSTATE AMODE=64 for the assembly." What happens, then, if you specify SYSTATE AMODE=64 but the code is executing in AMODE=31 ? - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64
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 like you have to specify the SYSSTATE macro in z/os 2.4. Joe Thanks Joe! I have the feeling that has changed for v2.4? The code (which worked fine on z/OS 2.3) had this comment: * NB: The SDWAPARM field points to an 8-byte area, when * * ESTAEX is issued "in AMODE 64" this is the 64-bit * * address passed in the PARAM field of the ESTAEX* * invocation. But "in AMODE 64" is a mis-nomer; * * this is only true if SYSSTATE AMODE=64 is specified* * when ESTAE is invoked. When that is _not_ true, * * this field contains a 4-byte address and a 4-byte * * ALET (as it does for a regular 31-bit assembly.) * * However, the exit is still given control in AMODE * * 64 if ESTAEX was invoked in AMODE 64. * So - there was clearly some confusion at some point in the past... And - the way we had solved it was to not specify SYSSTATE AMODE=64 and to let things go with the 32-bit mode SDWAPARM... but - at least empirically, the ESTAE EXIT was still driven in 64-bit mode. (But - since we didn't know the AMODE of the ESTAEX, we had to handle the EXIT running in 31-bit or 64-bit anyway.) So - perhaps the "fix" for now is to just drop to AMODE=31 to issue the ESTAEX and let the ESTAE EXIT get entered in AMODE=31 and go with that... I hope, if the current AMODE at the time of the exception is 64-bit we still get all the 64-bit info... we'll see... Or - I suppose - we could test the AMODE at the point where the ESTAEX is to be done, and have dual-paths (one assembled with SYSTATE=64 and one without?) I'll try and dig up the older doc to see what it says... - Thanks again! - - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64
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 makes sense. "Hey assembler, when you assemble MVS macros, > assume that the XA instructions are available." That makes sense. Your > routine might get called by code running on a pre-XA box? Then don't > specify that ARCH -- it will then work either way. > > But for AMODE -- well, code is either AMODE 31 or AMODE 64 -- it's not > permissive; it's not both. There is no AMODE ANY. So what do you specify > for SYSSTATE if you have code that can run either way? > > Charles > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64
SYSSTATE has never entirely "felt right" to me. For some things -- like ARCH -- it makes sense. "Hey assembler, when you assemble MVS macros, assume that the XA instructions are available." That makes sense. Your routine might get called by code running on a pre-XA box? Then don't specify that ARCH -- it will then work either way. But for AMODE -- well, code is either AMODE 31 or AMODE 64 -- it's not permissive; it's not both. There is no AMODE ANY. So what do you specify for SYSSTATE if you have code that can run either way? Charles -Original 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 (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 specify the SYSSTATE macro in z/os 2.4. Joe On Mon, Mar 23, 2020 at 4:30 PM 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 SYSTATE AMODE=64. > > 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. > > Of course - this doesn't work well when AMODE=64 and my > program gets lost. > > This didn't seem to happen with zOS 2.3 - we've recently upgrade > to zOS 2.4. > > Anyone seen anything like that for newer zOS? > > I _suppose_ I could always drop to AMODE 31 for invoking ESTAEX, > but then my ESTAE exit would be in AMODE 31, and I'd prefer for it > to be in the AMODE at the time ESTAEX is called... > > This "feels" unlikely - as the PC is hopefully just going to stack the > current PSW address for its return... and I'd be very surprised > of something changed that... but - I thought I would just toss > that out to see if anyone has an idea. > > - Thanks - > - Dave R. - > > > > > -- > riv...@dignus.comWork: (919) 676-0847 > Get your mainframe programming tools at http://www.dignus.com > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE 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 specify the SYSSTATE macro in z/os 2.4. Joe On Mon, Mar 23, 2020 at 4:30 PM 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 SYSTATE AMODE=64. > > 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. > > Of course - this doesn't work well when AMODE=64 and my > program gets lost. > > This didn't seem to happen with zOS 2.3 - we've recently upgrade > to zOS 2.4. > > Anyone seen anything like that for newer zOS? > > I _suppose_ I could always drop to AMODE 31 for invoking ESTAEX, > but then my ESTAE exit would be in AMODE 31, and I'd prefer for it > to be in the AMODE at the time ESTAEX is called... > > This "feels" unlikely - as the PC is hopefully just going to stack the > current PSW address for its return... and I'd be very surprised > of something changed that... but - I thought I would just toss > that out to see if anyone has an idea. > > - Thanks - > - Dave R. - > > > > > -- > riv...@dignus.comWork: (919) 676-0847 > Get your mainframe programming tools at http://www.dignus.com > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64
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 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. Of course - this doesn't work well when AMODE=64 and my program gets lost. This didn't seem to happen with zOS 2.3 - we've recently upgrade to zOS 2.4. Anyone seen anything like that for newer zOS? I _suppose_ I could always drop to AMODE 31 for invoking ESTAEX, but then my ESTAE exit would be in AMODE 31, and I'd prefer for it to be in the AMODE at the time ESTAEX is called... This "feels" unlikely - as the PC is hopefully just going to stack the current PSW address for its return... and I'd be very surprised of something changed that... but - I thought I would just toss that out to see if anyone has an idea. - Thanks - - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
