Integration
This is an IBM Automation portal for Integration products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
Hi Steve,
Without trace there is some basic information in the dump which can be used to figure some of what the abending task was doing. But not that much.
Trace gives a lot more detail, and comes with an increased cost. However trace needs to be on prior to the dump to really get that value.
I don't think what's being asked for here is really feasible without adding too much runtime cost, so I will decline this idea.
Regards, Matt.
Hi Matt,,, As i don't have a clear understanding on what is actually collected via trace,,,,
My thought was that when a dump occurs,, that there might be enough information to be gathered at that point on ? It would at least have some detail that could help point us in the right direction....
Question is ,,, how often in troubleshooting dumps are the pertinent pieces of information prior to the dump more telling than durning/after the dump ?
Maybe this just howling at the moon ,,,,
Thanks for taking the time ,,,,,
Hello,
We only capture trace information when trace is on. So switching trace on at the point when the dump occurs will not capture any information leading up to the dump. It will just capture information from the point of the dump onwards.
Is that what you were asking for - automatically switching trace on when the first dump occurs, so that if a second dump occurs we will have some trace?
Or alternatively was the request for a small circular trace buffer that was always on so it could be dumped out? If so that's pretty close to what existing trace does and will come with the same, or similar performance impact.
Regards, Matt.