Re: SLIP and ESTAE

2016-01-16 Thread Skip Robinson
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
jo.skip.robin...@att.net

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Jim Mulder
> Sent: Friday, January 15, 2016 05:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN


SLIP and ESTAE

2016-01-15 Thread Paul Schuster
Hello:

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?

Thank you for any insight you can provide.

Paul

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: SLIP and ESTAE

2016-01-15 Thread Jim Mulder
> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN