Browse Prior Art Database

Determining the co-relation and dependency of various problem diagnostic aids through the Product Trace.

IP.com Disclosure Number: IPCOM000226039D
Publication Date: 2013-Mar-21
Document File: 5 page(s) / 32K

Publishing Venue

The IP.com Prior Art Database

Abstract

For an effective and efficient problem determination of a software product problem a coherent set of diagnostic docs from the time of problem occurrence are very important . This article describes a methodology to determine the co-relation and dependency of various problem diagnostic aids or docs through the activation of product trace so that only the right set of diagnostic documents are collected for problem analysis.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 29% of the total text.

Page 01 of 5

Determining the co-relation and dependency of various problem diagnostic aids through the Product Trace.

Problem / Background

For an effective and faster problem determination, it is important that a software product support engineer has all the necessary documents available from the problem situation. It is often the case the support teams receive incomplete set of docs or they receive too many documents that may be unrelated in terms of the time of occurrence to the problem situation or unrelated to the problem itself. This mismatched diagnostic doc collection is more apparent in manual way of collecting the docs usually because the end user may not be skilled enough or not fully aware of Problem Diagnostic capabilities of the product .

This problem is alleviated to some extent by means of diagnostic doc collector tools that are shipped with some of the software products. These tools provide an automated way of collecting the documents and helps prevent issues of incomplete document collection but still cannot address the issue of correlated docs from the time of occurrence.

These tools collect the same set of docs irrespective of the problem type.

These Problem Determination collector tools typically have the predefined problem situation categories. For example :


1) General configuration issues


2) Abend or dumps


3) Runtime errors


4) Startup problems

and have a fix set of docs that are to be collected for each of these categories.

The drawback of this system is that as the product keeps changing its diagnostic facilities could also undergo changes . So what was applicable before may not be entirely true now. So diagnostic tool would constantly need to undergo the changes to maintain the up-to-date list of diagnostic docs to be collected for each of these categories. Also it does not consider the true set of diagnostic docs affected for a particular problem that is being attempted to be captured. So it may end up collecting too less or too many docs because of the hard coded fixed set of document list .

When a problem is reported by a customer , one of the main diagnostic document usually asked by support engineer is the product 'trace', that captures the problem situation/event. So the trace is usually collected by the diagnostic collector tools
for most of these problem categories. It is often required that the other supporting documents are also collected along with the trace to aid the investigation. and usually it is the error logs, abends or FDC (First Data Capture) and they must also be from same time frame as that of the traces so that they can be co-related for the holistic view of the problem.

So instead of hard-coding a fixed set of docs for collection inside the data collector tool, it

1


Page 02 of 5

would be more efficient and effective if the trace mechanism can be made more intelligent and self aware to dynamically determine what are the other affected
logs that would also need to be collected along with it . When t...