> > We seem to have a loop in the DUMPSRV address space, causing > > continuous dump requests all containing the following dump title: > > > > > "COMPON=SSI,COMPID=5752SC1B6,ISSUER=IEFJSARR,MODULE=IEFJRASP,ABEND=S0C4,REASON=00000011,SNAME=EYUX" > > > > The system is not down so my PMR is only at Sev 2, but we'd like to > > suppress dump requests containing all, or as many as possible, of > > the symptoms in the "dump title" cited above. > > > > Can someone suggest an appropriate SLIP to set? > > I have the unfair advantage of being able to view the dump > you sent to IBM for your PMR. Using that, I would suggest > > SLIP SET,A=NODUMP,C=0C4,DA=(14R,EQ,80CA9100),ID=SSI,END > > The 0C4 abend is occurring because the SSVT for subsystem EYUX > has been completely overlaid, so every broadcast SSI request > is taking the 0C4 abend when it tries to call what it thinks > is a function routine. R14=80CA9100 is common to all of the > abends because that is the return address in the z/OS SSI > module which is making the call to the bogus function routine > address.
Since I was looking at your dump anyway to recommend the SLIP trap, I might as will also note that the SSVT, at address BC3690, appears to be overlaid by data similar to what is in the storage area starting at address BC1000, which was obtained for a length of x'2000' by an ISV product, at time 01/14/2014 09:09:04, which is around when your 0C4 abends started occurring. This can be found in the report from VERBX VSMDATA 'OWNCOMM DETAIL CONTENTS(NO) SORTBY(ADDR)' So it seems likely that the SSVT overlay is due to the ISV product storing beyond the area which it obtained. I will put some more detail about the identity of the ISV product into your PMR. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
