Catalog processing is not my area of expertise, but I think that this symptom record is the result of a catalog service task being ABTERMed with code 91A, possibly by a catalog analysis task. I don't remember offhand if a 91A is also used to terminate a service task when the suspended requesting task gets ABTERMed. I would suggest looking at the syslog to see if there are any catalog messages at the times of these symrecs which might explain the situation. Absent that, I would do SLIP MOD,ID=X91A,DISABLE to get a dump of a 91A abend, and look at that. You may need to open a PMR to catalog for assistance with dump analysis. I would at least look at the SYSTRACE in the dump to see who initiated the 91A ABTERM.
Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on 06/15/2017 05:20:21 PM: > From: Turner Cheryl L <cheryl.l.tur...@irs.gov> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 06/15/2017 11:03 PM > Subject: Re: EREP Symptom and/or Software Records > Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > > I understand why you may have thought that but no I understand it is > not the slip that spawns the records. But couldn't it be said that > the slip parms are indicating IBM's view of the severity of the > event? I am so new to this that heck I may not be even asking the > questions right. For that I'm sorry. > > For example. Here is one symptom record in particular we are > constantly seeing (there are others but let's use this as an example): > > PIDS/5695DF105 RIDS/IGG0CLA9 RIDS/IGG0CLX0#L PRCS/000000F6 PRCS/00000000 > PRCS/00000000 JOBN/DBP1DBM1 <==== > the JOBN changes but they all seem to be DB2 related tasks. All > the other information is the same. > > SYSTEM ENVIRONMENT: > CPU MODEL: 2964 DATE: 166 17 > CPU SERIAL: 0207C7 TIME: 01:06:27.72 > SYSTEM: MBI2 BCP: MVS > RELEASE LEVEL OF SERVICE ROUTINE: HBB77A0 > SYSTEM DATA AT ARCHITECTURE LEVEL: 10 > COMPONENT DATA AT ARCHITECTURE LEVEL: 10 > SYSTEM DATA: 00000000 00000000 |........| > COMPONENT INFORMATION: > COMPONENT ID: 5695DF105 > COMPONENT RELEASE LEVEL: 220 > SERVICE RELEASE LEVEL: UA82137 > DESCRIPTION OF FUNCTION: CATPROB DATA > > PRIMARY SYMPTOM STRING: > PIDS/5695DF105 RIDS/IGG0CLA9 RIDS/IGG0CLX0#L PRCS/000000F6 > PRCS/00000000 JOBN/DBP3DBM1 > > SYMPTOM SYMPTOM DATA EXPLANATION > --------------- ------------- ----------- > PIDS/5695DF105 5695DF105 COMPONENT IDENTIFIER > RIDS/IGG0CLA9 IGG0CLA9 ROUTINE IDENTIFIER > RIDS/IGG0CLX0#L IGG0CLX0#L ROUTINE IDENTIFIER > PRCS/000000F6 000000F6 RETURN CODE > PRCS/00000000 00000000 RETURN CODE > JOBN/DBP3DBM1 DBP3DBM1 JOB NAME > > THE SYMPTOM RECORD DOES NOT CONTAIN A SECONDARY SYMPTOM STRING. > FREE FORMAT COMPONENT INFORMATION: > > And then there appears to be a snap dump of storage on each one. > > Nothing on IBMLINK matching anything that I can think to search on > from the fields. In the syslog we see IBM slip trap x91A taken > about the time of each record. > 2017166 01:06:27.72 00000284 IEA989I SLIP TRAP ID=X91A > MATCHED. JOBNAME=CATALOG , ASID=0086. > > And there are sometimes 100s of this particular symptom records on a > given lpar, per day. > Slip settings are: > ID=X91A,NONPER,ENABLED > ACTION=NODUMP,SET BY CONS INTERNAL,RBLEVEL=ERROR,COMP=91A > > 91A > > Explanation: A request to abnormally end the catalog address space (CAS) > service task was issued either through the MODIFY CATALOG,RESTART command, > or through catalog analysis task processing. > > System Action: The system re-drives the catalog request currently in > process. > > We are not issuing a MODIFY CATALOG RESTART command at the time of > any of the logrecs being cut. SO might there something wrong with > the catalog process that all these redrives are necessary? Is it > normal behavior? So many questions and I'm clueless, unfortunately. > > So what I guess I was trying to wrap my head around is: if there > isn't a need to take a dump, etc. (as specified in the SLIP setting) > then why have logic to cut 100's of symptom records at all for that > particular issue? And if we're cutting 100's of records - is it > really a problem? And like Ed said, it's noise, and I don't know > enough to know it's a problem or not and sometimes how to go about > diagnosing. So I was hoping to get some help (which I have) in how > to handle these and others going forward. > > Thanks for your and others responses, though. It's much appreciated > and I'm taking it all in as much as I can. > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
