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 80000000 00000000 0xxxxxxx 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 8xxxxxxx 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 [email protected] with the message: INFO IBM-MAIN
