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
