Well, I now know a little more and am a little mystified. I had this sudden thought that perhaps the difference at the one customer was that the two S0C4's we have experienced there would have happened in assembler code running AMODE 64. (The C++ code is all AMODE 31.) So today I coded up some test code to force a S0C4 in AMODE 64 and sure enough, same results, system SYSUDUMP, no LE recovery.
I added some debugging WTOs to the ESTAE recovery so I could see what was happenning. My ESTAE recovery routine is getting driven. I am (as intended) percolating. LE's recovery routine -- which admittedly I am abusing a bit -- apparently is boggled by AMODE 64 and is in turn percolating to MVS. That at least would explain what I am seeing. So my questions today to this august group are 1. In what AMODE will a recovery routine be entered if the ESTAE was issued in AMODE 31 but the exception happened in AMODE 64? I don't see that in the manuals. (It's probably there -- I just don't see it.) 2. If the answer to (1.) is AMODE 64, how do I change that? I tried SETRP RETRYAMODE=31 but got an MNOTE that it was invalid with Percolate (and admittedly, the parameter is RETRYAMODE, not PERCOLATEAMODE -- it is for retry, not percolation). Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Charles Mills Sent: Friday, August 25, 2017 4:08 PM To: [email protected] Subject: Why would LE not trap? I have a C++ program compiled with #pragma runopts( POSIX(ON),TRAP(ON,NOSPIE),NOEXECOPS ) I have my own ESTAEX. On an ABEND, if SDWACLUP is not set, I percolate, presumably to LE's ESTAE and it drives my C Signal catcher. It works. In testing, and at most customers, a S0Cx drives the Signal routine, 100% of the time. But one customer has twice gotten a S0C4 and in both cases we got an old-fashioned SYSUDUMP with no Signal. I don't know if we came through the ESTAEX exit or not. The ESTAE exit logic is not at all complex so some subtle bug is unlikely. The reported S0C4 is in the main logic, not in the ESTAE recovery. The fact that it is consistent at one customer leads me to think it is an environmental factor, not a logic error. There are no LE options in PARM= or CEEOPTS. Environment is STC, current release of z/OS (not sure exact version but probably V2R1). What should I be looking for? What would effectively override TRAP(ON)? Would SDWACLUP ever be set on a vanilla S0C4? It's at a customer and the S0C4 is extremely infrequent so "try this/try that" is not an option. Why my own ESTAE? So I can deal with unrecoverable ABENDs, which LE will not. Why NOSPIE? So everything comes through the ESTAE. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
