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 <[email protected]> wrote: > <snip> > 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. > </snip> > > 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'0000' 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 [email protected] with the message: INFO IBM-MAIN > -- sas ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
