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 <riv...@dignus.com>
wrote:

:>Peter Relson 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 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 AOUT            TIME 170714   DATE 20083    
:>ID = 000
:>   CPUID = D301BF6B1090   PAGE 00000001
:>0COMPLETION CODE      SYSTEM = 0C2      REASON CODE = 00000002
:>
:>
:>
:>   PSW AT ENTRY TO ABEND   078D1001  9F90B1C2  ILC  04  INTC  0002
:>
:>0PSW MODULE     ADDRESS = 00000000_1F900880  OFFSET = 0000A942
:>
:> NAME=AOUT
:>
:>
:>which is a 31-bit PSW in the dump?
:>
:>Here's the bytes at 1F90B1A0-1F90B200:
:> 1F90B1A0 10009604 10005020 10089201 10034100    000058E0 001058EE 
:>030458EE 00B0B218   *..o...&...k........\............*
:> 1F90B1C0 E000B904 00D4E380 C0A40014 B90A0087    BF8F8004 4770C15A 
:>000050F0 D0A8E3F0   *\....MT.{u.....g......A!..&0}yT0*
:> 1F90B1E0 C0A40014 B90A00F7 A7180000 5010F004    E3F0D0A8 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:    1000            LPR   0,0
:>   0x1f90b1a2:    9604 1000       OI    0(1),4
:>   0x1f90b1a6:    5020 1008       ST    2,8(0,1)
:>   0x1f90b1aa:    9201 1003       MVI   3(1),1
:>   0x1f90b1ae:    4100 0000       LA    0,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       PC    0(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 -

--
Binyamin Dissen <bdis...@dissensoftware.com>
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

Reply via email to