Cheryl, So, IBM supplies many standard Slip Suppressions. the ACTION would be NODUMP. This is due to various events in z/OS that will just issue them, 91A, 133, D37, B37, E37 just because dumps are not really needed and "everyone" just knows what they are. I consider these annoyance and just part of the process.
As for Logrec, IBM uses the philosophy, just in case - create a logrec record. Sometimes with storage sometimes without storage. This is incase you need to go back and look for symptoms about an event. If the Logrec data is kept longer than a day then you would be able be able to go and see if there are system control block information that could be helpful in diagnosing the issue. What I usually go by are the following guidelines 1) How often is the event occurring -----Original Message----- >From: Turner Cheryl L <[email protected]> >Sent: Jun 15, 2017 2:20 PM >To: [email protected] >Subject: Re: EREP Symptom and/or Software Records > >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 [email protected] with the message: INFO IBM-MAIN
