I think the easiest way to test is to just zap your code to take the unrecoverable path. Or, you could try the DETACH, try your other things, and tell us what happens.
I suppose you could write another ESTAE recovery to set SDWACLUP for the "real" routine (for testing). Abends in recovery routines are pretty nasty :-). So thorough testing is a really good idea. sas On Thu, Apr 11, 2019 at 1:13 AM Tom Brennan <t...@tombrennansoftware.com> wrote: > I spent hours one time trying to figure out why my DC H'0' resulted in > an 0C4. Turned out someone coded a bad address in the ESTAE routine, so > *every* abend turned into an 0C4. > > ... > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Charles Mills > > Sent: Wednesday, April 10, 2019 4:40 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Programmatic way to create unrecoverable ABEND? > > > > Is there a reasonably easy way for a task to create an ABEND that ESTAE > or FRR will indicate is unrecoverable (SDWACLUP)? (I can't use console > CANCEL because I need the ABEND to occur within a fairly specific range of > machine > > instructions.) > > > > > > > > Will issuing a DETACH "for myself" do it? ABEND X'222',,SYSTEM won't do > it, right? S222 is normally unrecoverable, but not if done from a normal > ABEND macro? > > > > > > > > The doc for DETACH says the issuer cannot have an EUT FRR. What if it > does? > > > > > > > > I'm not just trying to make trouble. I am trying to test FRR logic for > dealing with an unrecoverable ABEND. > > > > > > > > Charles > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
