Barbara, I knew you would be up to helping me on this do to your very gentle postings that I have been reading ;-D
We had a rash of errors coming out of a vendor product so we set a slip trap. So, without the GRSQ, they are saying "we cannot debug your problem" because it is missing. And of course we cannot willingly recreate the problem. So, I will enhance our settings to be a bit more "everything no matter what" in the dump. Lizette > > >I have a situation where a vendor is looking for GRS data in an > SVCDUMP and > >says it is not there because we do not have in our SDATA GRSQ > > Let's just say this: How did the dump get taken? Error in the vendor's > product? > Vendor product dump? If so, beat them for not including what is needed > in > their dumps. > Dynamic dump or slip dump requested by the vendor? see above. > Is this a lockout problem of some kind? I have heard the old excuse > 'you didn't > set this-or-that-parm, so we cannot debug your problem' once too often, > so I > unless the basic problem was a lockout problem, to me this smells of an > excuse. > > >Is that correct? If I do not code the GRS parm in SDATA it is not in > the > >dump at all? If so, what are the basic must haves in the SDATA for > SVCDUMP. > > I believe that GRSQ asks sdump to give control to the global and/or > local GRS > exit, so that would be the only way to get those data into an sdump. > > This is what I have set: > COM='CD SET,SDUMP=(GRSQ,NUC,SQA,RGN,LPA,PSA,SWA,CSA,SUM),Q=NO' > COM='CD SET,SDUMP=(LSQA,TRT,XESDATA)' > COM='CD SET,SDUMP,MAXSPACE=1500M' > > This set is not a 'basic minimum', it is a 'set-it-and-forget-it' to me. > For the > simple reason that most sdump requests don't specify all the needed > options, > but those are additive, anyway. I have heard the excuse "you did not > set > allnuc like we requested, so we cannot look at that dump", and that for > a > product that has no ties whatsoever in the nucleus, indicating > incompetence > on the vendors part. > > At to these options a reasonably sized system trace table (ours go up > to 8M > per processor), and the excuse 'data are not in dump' should be a thing > of the > past. > > Regards, Barbara > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
