Seymour you are right hard to trace balr bassm etc That’s why when I have a large number of routines I use link macro rather balr bassm
Regardless the idea is to get as close as possible to where the problem occurred Joe Reichman On Tue, Nov 28, 2023 at 10:03 AM Seymour J Metz <sme...@gmu.edu> wrote: > There is another case: > > The program calls a service routine pointed to by, e.g., the CVT. An ABEND > in the service routine will not be at an address associated with the RB's > CDE or LPDE, ut will be elsewhere in, e.g., the nucleus, LPA. > > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > ________________________________________ > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf > of Joseph Reichman <reichman...@gmail.com> > Sent: Tuesday, November 28, 2023 8:48 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Abend producing SDWARBAD > > Peter > > Let then be specific > > The first thing I do is get the low and high address of the program The > program name is being passed as a parm to the Estae routine > > The case of where the abend happened in the program is handled nicely by > file 192 > > The case of where the error PSW is not in the program range lend themselves > to 2 possibiltles > > 1) a wild branch so if register 15 is zero the following code will yield a > next address of 2 in the error PSW BAS R14,2(R15) > > 2) it would have to match RBOPSW of one of the rb’s in the rb chain > > If the RB is a SVRB then chain back and look for the PRB RB that called the > SVC and that PRB should have the user program abend registers > > Thanks > > > > Joe Reichman > > > On Tue, Nov 28, 2023 at 8:38 AM Peter Relson <rel...@us.ibm.com> wrote: > > > "Asked to update" does not shed much light. I wouldn't bet that I'm > > allowed to look at the CBT tape files (the word bandied about is > > "contamination"), so I don't know what file 192 has. "Asked to update" in > > what way? > > > > A "general recovery routine" is highly unlikely to be overly useful. That > > is because recovery generally is not "general", rather it is unique to > the > > code it is intending to cover. But I don't know what the author intended > to > > mean by "general recovery routine". > > > > We have what we call "minimum RAS guidelines" that refer in part to data > > to make sure is placed into the SDWA in case it is recorded. > > That's something that is indeed "general". > > > > What exactly are you trying to accomplish? What actually is a "general > > recovery routine"? I hope it's not a recovery routine that is supposed to > > be able to work whether the recovery was established via SETFRR, ESTAE, > > ESTAEX, ARR-definition, IEAARR, ESTAI-definition? That can be quite a > > challenge (it's not obvious it's fully possible to accomplish without > input > > via the parameter; I have not tried). > > > > So I will ask again: what are you trying to accomplish? More > specifically, > > what are you trying to do with SDWARBAD? > > > > Why is it important if the abend code (completion code) is in the RB? The > > completion code is in the SDWA (as long as there is an SDWA, and if there > > isn't an SDWA you don't have SDWARBAD anyway). If it was indeed an > "abend" > > issued by a task then the register 1 slot of some RB will have the abend > > code because Abend itself is a type 2 SVC. Abend's can be issued by > CALLRTM > > TYPE=ABTERM as well, for example. > > > > If you'd like opinions on what you're doing (especially since this is for > > general consumption), then please ask questions that will get you the > > answers you need. > > > > Peter Relson > > z/OS Core Technology Design > > > > > > ---------------------------------------------------------------------- > > 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
