Sorry. I meant "In what AMODE will a percolation routine be entered?" but I guess the answer is "in the AMODE of its ESTAE (but not 24)."
Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Jim Mulder Sent: Sunday, August 27, 2017 1:42 PM To: [email protected] Subject: Re: Why would LE not trap? AMODE ESTAE-type recovery exits receive control in the AMODE that was current at the time-of-set (time-of-PC AMODE for ARRs) with the following exceptions: ?ARR, IEAARR, and ESTAEX exits receive control in AMODE 31 instead of AMODE 24 when established for AMODE 24 programs Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > From: Charles Mills <[email protected]> > To: [email protected] > Date: 08/27/2017 01:38 PM > Subject: Re: Why would LE not trap? > Sent by: IBM Mainframe Discussion List <[email protected]> > > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
