AMEN! You should NEVER send a dump to any vendor without at least doing some cursory dump analysis.
Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Thursday, July 06, 2006 11:44 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Dump Reading (was Re: LSQA shortage) Veilleux, Jon L wrote: > It should be mandatory to debug a dump every so often just to keep > your skills up. Even if you have to create the dump yourself. > Mark Z was right when he guessed that most of the dumps Chris and I read are produced by products for which we have the source code. But, in my case, I certainly don't stop there. I make it a point to analyze (albeit sometimes just briefly) every dump I send to IBM associated with any PMR I've opened. And, every once in a while, that analysis comes in handy! IBM has some absolutely amazing dump readers. (Jim Mulder and Nadine Goldberg have to be at or near the top of the list!) But, even some support technicians at IBM are afraid of reading dumps. I've experienced numerous situations in which it was obvious that Level 2 was doing everything possible to avoid that "chore" -- sending me off to gather input parameters, logs, attempt additional recreates, etc. when all anyone had to do was crack open the dump for a few minutes (with the program listing handy) to understand what went wrong! I had one such incident in which RMM was down for _three days_ while Level 2 flapped around like a fish on the ground until, out of desperation, I contacted Mike Wood (RMM guru and IBM-Main participant), who figured out the problem and provided a workaround after only _ten minutes_ of dump analysis -- something the Level 2 technician had never even attempted! There have been other cases in which I've found myself leading the dump analysis process from my end (sometimes with and often without source code or listings!) because Level 2 was asking all the wrong questions and I knew it because I had already looked at the dump myself! Recently, I've started saying things like, "I'm sorry. The information you've asked for is no longer available on my system. You'll just have to solve this problem the 'old fashioned' way -- by analyzing the dump!" I'll even start the ball rolling by providing as much as I know about the problem. It's amazing how quickly things progress when people start actually focusing on the wealth of information provided by the dump! Postmortem problem analysis is an area in which the mainframe remains light-years ahead of other platforms. It's truly a cultural difference. The direct and demonstrable result is the quality and reliability of our software. We should not allow ourselves to lose that important differentiator. Reading dumps can be fun. Do it when you can and you'll be helping to keep the mainframe community's postmortem problem analysis skills current... -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ ---------------------------------------------------------------------- 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 ----------------------------------------- This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna ---------------------------------------------------------------------- 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
