First, something "bad" happened somewhere and very likely left some forensic evidence. Then EXCP's recovery routines were invoked and decided to classify the error as an S800-4 ABEND. Then maybe a dump was produced. I suggest you look at the System Trace that is in your SYSUDUMP (you do have one, right?), find the SVC 13 (base 10) that was issued that resulted in the S800-4 error message and dump, then work backwards in the system trace looking for previous entries that are (1) from the same address space as yours and (2) have an "*" in a column that is almost always blank. That "*" indicates that something most unusual happened as part of that entry. Then try to analyze that error rather than the S800-4 situation .
Another possible approach is to find the SDWA and/or RTM2WA control blocks in your SYSUDUMP and look for fields in those control blocks whose DSECT descriptions say something like "earliest error", "original error", or some words like that. Those kinds of fields will probably correspond to that system trace entry with the "*" in it. If you can't find fields like that quickly in the SDWA or RTM2WA, then look at each field in both control blocks, read the DSECT description for that field, and think about what the description says - is that field associated with the original error or with something that happened much later in the recovery/termination process? There are hundreds of fields. It takes time and determination. Usually there is forensic evidence somewhere, just like on television. Another possible source of early forensic evidence is software records in SYS1.LOGREC. Also look for an EXCP Debugging Area, pointed to by the TCB that was ABENDed. If you can find that, you may have a PSW and registers at the instant that the original error occurred. You may have to ask for help in finding a DSECT of the EXCP Debugging Area, however. I used to know where that one is documented, but I haven't needed to use it in lots of decades, so I don't remember now. Bill Fairchild Franklin, TN ----- Original Message ----- From: "Micheal Butz" <michealb...@optonline.net> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 30, 2013 2:56:39 PM Subject: Re: System abend 800 reason code 4 For reason code 4 the explanation says A program issued a SVC 114 the EXCPVR macro but a error occurred durning page-fix or page-unfix processing A page-fix error can occur If the EXCP processor tries to fix pages That are not assigned to the callers ASID The blksize in the program is 27930 For this program maybe for dfsms To get that kind of buffer is problematic Ill look at the dcb parms to see what I can do Sent from my iPhone On May 30, 2013, at 4:34 AM, Binyamin Dissen <bdis...@dissensoftware.com> wrote: > On Wed, 29 May 2013 22:22:33 -0400 Micheal Butz <michealb...@optonline.net> > wrote: > > :> Running a program under TSO TEST > :>I got the above abend after a BSAM READ. Would anyone know what this is > about > > What did you understand from looking up the abend in SYSTEM CODES? > > -- > Binyamin Dissen <bdis...@dissensoftware.com> > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, > you should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, > especially those from irresponsible companies. > > ---------------------------------------------------------------------- > 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
