Rob You are correct but I can tighten it up
The code is old no 64 bit gpr s Pointing to the right registers SDWA or from RB When I worked at ASG the systems group had recovery routine used by every product / TMON for …. I didn’t put in a SDUMP option All I’m saying it’s an old file and it will be in better shape Thanks > On Nov 29, 2023, at 6:52 AM, Seymour J Metz <sme...@gmu.edu> wrote: > > CSVQUERY can provide the name and load point. If there is only one version > of the module, or if you can figure out where it came from, then you can use > a mmodule map from, e.g., AMBLIST, to determine the CSECT. Unfortunately, > CSVINFO and CSVQUERY do not return a DSN or path. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > ________________________________________ > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of > Jon Perryman <jperr...@pacbell.net> > Sent: Tuesday, November 28, 2023 8:08 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Abend producing SDWARBAD > > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
