The reason it hung was when I started to debug the recovery I had NOT linked it REUS The way I debug I do a TEST command For the driving code
LOAD the recovery module and do a breakpoint at +0 Thus everytime the module was invoked a new copy was loaded Sorry > On Nov 29, 2023, at 11:32 AM, Peter Relson <[email protected]> wrote: > > Jon P wrote (somewhat tongue in cheek) > <snip> > When did IBM start creating minor CDE's for each csect in a load module? > </snip> > > We all know that the answer is "never" and (to the unasked question) "never > will". > > It sounds like the idea is not to find information about the program that > blew up but rather about the program that called the program (perhaps more > than one level of indirection away) that blew up. That could be dangerous to > do in a recovery routine (whose primary goal is to fix while doing no harm, > and whose secondary goal is to capture diagnostic data, similarly while doing > no harm). > > SDWANAME, when it's not SDWARBAD, tries to find the module name. PRB's might > have an associated CDE (an example of a case where a PRB does not have an > associated CDE is the PRB created for SYNCH). If the abending RB is a PRB, > RTM uses that RB's RBCDE1 field (when non-zero) to locate the CDE and extract > the name. For an IRB, it uses CSVQUERY based on the entry point address in > the RB. > > The other posters have mentioned a lot of situations that are not possible to > deal with if using intended interfaces. Sure you could do a CSVQUERY for > JPALPA and even a NUCLKUP. If you do such things you ought to make sure you > have nested recovery to handle the case where a problem occurs within those > routines. And a "general recovery routine" would have to cover the > cross-memory case where the current primary is not the home address space > (RB's are in the home address space). > > Joe R started this whole discussion with a point about TSO TEST hanging. I > proved that it does not always do so, so Joe needs to consider the > possibility that he's doing something in his test environment that is causing > this to happen. > > Peter Relson > z/OS Core Technology Design > > > ---------------------------------------------------------------------- > 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
