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 <[email protected]> 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 [email protected] 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 <[email protected]> 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 [email protected] with the message: INFO IBM-MAIN
