My view of recovery routines may have been jaded by an experience early in my career. We sysprogs were implored to debug an application that was taking truly bizarre abends. One repeatable abend was in a DFSORT routine. Another was in a printer error handling routine. Trouble was, it was a straight COBOL program that was neither sorting nor printing.
After spending hours on a Saturday morning with various sysprog tricks and tools, the problem boiled down to this. At initialization, the application called a years-old recovery setup program that no one knew anything about. Somewhere along the line, the COBOL program took a S0C7 as application programs are wont to do. The recovery routine got control and screwed up registers, which led to a wild branch that seemed most often to land in the middle of either DFSORT or hardware error correction modules. That inevitably led to a head-scratching S0C4. The solution was to replace the old recovery setup program with an IEFBR14. I have not been a fan of recovery routines ever since. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Saturday, September 19, 2015 6:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Recovery routine for ICHRTX00 >I lean against recovery actions for system exits I don't specifically disagree with this. Three main reasons to have recovery come to mind -- to release resources that you have obtained -- to gather diagnostic data to help debug your error -- to protect your caller from unexpectedly getting control in its recovery The first is critical. But most exits do not obtain any resources (especially if they can be given dynamic storage to work with). The second is, to a customer, "up to you". The importance of third depends on the code calling the exit. 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
