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