You can always determine if it’s a CSECT whitin many by seeing if it’s a minor CDE
There isn’t a 100 % catch all but it tightens up the code On Tue, Nov 28, 2023 at 8:09 PM Jon Perryman <jperr...@pacbell.net> wrote: > Hi Joseph, > > Just so everyone is clear, you're upgrading CBT192 (generic abend > diagnostics / recovery - ESTAEX, FRR, ARR, ...) to include new diagnostic > information. You're charged with mapping the abending address to a load > module and the offset into that load module which will be displayed as part > of the abend diagnostics. Ask yourself if this is useful except in the most > basic scenarios. > > There are flaws in using RB's (PRB, SVRB, IRB, ...) to determine the load > module. It doesn't work for PC routine abends captured by a PRB ESTAE. It > assumes that all load modules are executed using (LINK, XCTL, ...) which > creates an RB (PRB, SVRB, IRB, ...). It ignores the common practice of > using LOAD with branch tables. What about RBs that have terminated with the > abend percolated into the next RB? I'm sure there are more. > > I suggest that you code macros for new diagnostics you add. This > simplifies users' ability to choose, customize, replace and eliminate > functionality instead of having a single large module. In this case, I > suggest giving them a few options. > > Always ask yourself, where you could be exposing a normal sysprog to some > grief and how you should warn them of potential dangers. In my opinion, > everyone ignores the danger in the single most dangerous z/OS exit, The WTO > exit can be exposed to every possible z/OS restriction. Messages from RSM, > IOS and others can be issued from problematic states. For example, device > allocation because a disk volser is misspelled. > > You were asked specifically to display load module name and offset. I > personally find this useless because without a dump, you cannot identify > the CSECT with offset. You have an abend at some unknown CSECT name that is > linked in the load module. SMP/e complicates this further because it does > not do a complete link. Instead, it replaces modules (CSECTs) that have > been changed which changes the CSECT sequence. While you could provide this > as an option, the question is why? You can't determine the cause in any way > except that it was in a specific load module. > > I personally would provide a second option that can determine CSECT name > and offset using saveareas (possibly linkage stack).and base reg. You would > need to document how to be compatible with what people call baseless code > where a register points to literals. I don't know about how others > implement it. My personal implementation starts the csect with a SAVE > (14,12),,'module info' that never gets executed followed by the program > constants. To avoid loading constants to the instruction buffer, I have an > ENTRY statement where the executable code starts, followed by a SAVE > (14,12) and LARL Rxx,csect_name. This eliminates the need to calculate > offsets into the program. > > From a diagnostic standpoint, it looks like a standard program where a J > or B is followed by a length & eyecatcher. My recovery diagnostics find the > reg (R12 for my programs) that is within 12K of the failing address and > verify there is a J or B. > > A third option is to give sample code that requires user mods in the case > they don't follow standard conventions. > > You should ask the group because I suspect that others will have > recommendations and preferences. Maybe ask the assembler group too. > > On Tue, 28 Nov 2023 12:41:21 -0500, Joseph Reichman <reichman...@gmail.com> > wrote: > > >Sam asked me to update file 192 in cbttape > > > >Its a generic recovery > > > >I’m making two > > > >Updates > > > >1) when the error PSW isn’t in the program storage so I’m finding out if > the abend happened in a RB and then at what offset the user called that rb > >2) displaying 128 bit PSW and 64 bit gpr > >If then abend occurred while the user was in amode 64 > > > >That’s it > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
