>What good is the diagnostic data without the code? So you get a RC of >XYZ from a module you never heard of doing an undisclosed function. What >would that tell you?
>From experience (when I had OCO-access while I was IBM) I know that the return codes are usually described in some non-OCO manual/macro. The trick is to see which field in the hex stuff the RC *is*. Going through trace entries can give you a feel of what the code is doing. Looking at them long enough gets you a feeling what is normal for code flow. As in everything, you need to have spent considerable time (even with source code access) with them to be able to say if what you're seeing is right or indication of an error. >I would think that IBM would like us to debug our own problems (or at >least try) before 'bothering' them with diags. No. Until you find someone within IBM level2 who actually *knows* that there is such a thing as a ctrace, knows how to figure out who (what module) wrote it and can map it, IBM is pretty much clueless when it comes to ctrace entries. There are only a handful of people who can do it, and it is very hard to get through to them. >I told him that it was a waste of my time to look at dumps without source >code, and that I just called IBM and let them sort it out. That included >problems with vendor code and problems that I may have caused. See above. The problem is that IBM cannot do it, either (anymore?). Usually I have to get *VERY* forceful to get them to even analyze a problem. And it is even worse for us out here in the world, as everything not US is treated second class, IMO. We had one RSM ctrace problem, where IBM level2 told us that the address in question was not in the trace and we had taken the RSM ctrace incorrectly. I provided the ctrace entry to them and asked why they cannot see what I can see. It turned out that IBM had given us the wrong ctrace options. >Anyone know if a SHARE requirement for better trace info might get >anywhere? Or maybe enhanced IPCS formatting of the trace entries? It's >probably been tried before. No idea about the requirement. I agree with Ken that it would be nice to have more information about those entries. This would enable us to solve a few problems without IBM, and much faster, not to mention avoid reporting user errors. >They want the vendor (IBM in this case) to be responsible for any and all >problems and most problem determination. The reason is that a well >trained, knowledgable person can demand a higher salary. Problem is that IBM (or the vendors, for that matter) don't have these trained, knowledgable persons, either, for the same reasons. They cost more. So problems just don't get solved, because a) the customer doesn't bother to report the problem unless it is very pervasive and hinders operation or b) IBM doesn't have the skill to do problem determination. (Our Lotus Domino problems causing cluster outage are still not even close to getting analyzed, as IBM refuses to learn to read a linux sadump and doesn't get the core dump they're waiting for to start analyzing the problem, for three months now.) >This would have to be done product by product (or component by component). >The ctrace record format may be OCO but developers are certainly free to >write IPCS formatting routines. The TCP/IP team has a number of very good >formatting routime for the TCP/IP-related ctraces. As does WLM. Ever tried understanding what they tell you? (I quit.) Regards, Barbara -- Echte DSL-Flatrate dauerhaft für 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl ---------------------------------------------------------------------- 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
