I must admit to being quite twitchy at the thought of a general purpose recovery routine trying to be too clever.
I like to keep it as simple as possible and avoid making any recovery situation worse by going off the rails chasing unicorns during recovery logic. FWIW - the recovery design goals I use : (o) Locate the parm area passed by the routine that setup the recovery (o) Copy the diagnostic grab bag from the SDWA and populate the recovery parm area output fields (o) Decide if we are going to issue SDUMP/IEATDUMP based on caller provided options and/or the type of abend code (o) Create good VRADATA so that DAE can suppress duplicates (o) Restore registers using caller provided options and/or saved values in the parm area (o) If retry is possible and asked for then do so otherwise percolate The code I write normally has the recovery routine retry to a point in the mainline code that established the recovery. The mainline will also have access to the recovery parm area that contains the diagnostic grab bag. This mainline leaves breadcrumbs representing resources to release/handle during recovery and these can be processed by logic in the mainline. I also use a stack of recovery blocks so that the code can nest recovery requirements as logic dictates using PUSH/POP without having to go through ESTAE/ARR/FRR setup each time. Rob Scott Rocket Software -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Jon Perryman Sent: Wednesday, November 29, 2023 1:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Abend producing SDWARBAD EXTERNAL EMAIL 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 ================================ Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy ================================ This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
