I was once tasked with diagnosing a COBOL program that was taking S0C4 abends in a couple of different system modules that it had no business executing in the first place. I set a SLIP and discovered that the error started with a garden variety S0C7--as application programs are vulnerable to--then percolated to an ancient recovery routine that no one was even aware of. The recovery routine screwed up the registers and took one or another wild branch into LPA. Solution was to remove the errant recovery routine.
If SLIP had not received control before the recovery routine, I'd probably still be diagnosing. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile [email protected] > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Jim Mulder > Sent: Friday, January 15, 2016 05:38 PM > To: [email protected] > Subject: [Bulk] Re: SLIP and ESTAE > > > As designed, an ESTAE routine can recover from a (for example) 0C4 > > abend. The abend can happen, but the ESTAE can be coded so no one is > > the wiser than an abend has happened. > > > > However, if there is a SLIP set for (for example) C=0C4, it seems the > > SLIP and its action parms will take precedence over the ESTAE. > > So the nicely coded ESTAE which masks any abends is ignored, and the > > actual cause of the abend is exposed. > > > > I guess under certain circumstances this can be a good thing, but is > > there a way to have an ESTAE or some other recovery routine be immune > > to any SLIP processing? > > SLIP is called from RTM1 before any FRR exits, and from RTM2 before any > STAE/STAI/ESTAEX/ESTAE/ESTIA/ARR exits. And that is a good thing. > I don't want any recovery routines to be immune from SLIP processing. > > ESPIE exits are called before RTM (and thus before SLIP). And that is one of > the reasons why I despise ESPIE and recommend against using it. > > Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
