>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 [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
