Tom B wrote <snip> I was referring to my experience with a JES2 exit which setup its own recovery routine. In that code you could see it free any getmain'd memory, etc. like you mentioned. But also in that code was an error that caused an 0C4. So when the x'00' I added for temporary debugging ran that user-coded recovery routine, I was surprised to get an 0C4 instead and had to fix the recovery routine.
So of course JES2 had its own recovery routine in place that handled the 0C4 and we got a dump and JES2 went on its merry way, perhaps after disabling that exit (I can't remember). </snip> I took a weird view of what I suspect you really meant by "0C4 instead". I'm now thinking you just meant that you were surprised that the recovery routine did not complete successfully. But in case you were thinking of what happened to come to my mind, here's some info: When the x'00' "instruction" was executed, it would have gotten an operation exception and the most recently established recovery routine (see "special-case" below) would have gotten control for the 0C1. Its SDWA would have shown that. And TCBCMPC would be x'0C1000'. If that recovery routine then took some exception that resulted in an 0C4, a newer recovery routine (established by this recovery routine) or, in the absence of such, the next-oldest recovery routine would have gotten control for the 0C4. Its SDWA would have shown that . TCBCMPC would now be x'0C4000'. Special-Case: if you have established SPIE/ESPIE for a program interrupt, that exit will get control even if there is a newer-established ESTAE-type recovery routine. 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
