Abstract: A user interface includes a graphical topological representation of an information system. Information is collected regarding connections between switches, storage nodes and computer nodes in the information system. Any sub networks in the system are identified based on the collected information and classified as LANs or SANs. Connections between the various components are determined, and a layout of any identified LANs, computer nodes, SANs, and storage nodes is established for generating the topological representation in the user interface. The graphical topological representation of the information system is displayed in the user interface with the LAN icons, computer node icons, SAN icons and storage node icons laid out in a matrix-like arrangement of columns and rows, such that for LANs, computer nodes, SANs and/or storage nodes that are connected to each other, the corresponding icons are located on or near a same row in the graphical topological representation.

Abstract: A user interface includes a graphical topological representation of an information system. Information is collected regarding connections between switches, storage nodes and computer nodes in the information system. Any sub networks in the system are identified based on the collected information and classified as LANs or SANs. Connections between the various components are determined, and a layout of any identified LANs, computer nodes, SANs, and storage nodes is established for generating the topological representation in the user interface. The graphical topological representation of the information system is displayed in the user interface with the LAN icons, computer node icons, SAN icons and storage node icons laid out in a matrix-like arrangement of columns and rows, such that for LANs, computer nodes, SANs and/or storage nodes that are connected to each other, the corresponding icons are located on or near a same row in the graphical topological representation.

Abstract: A root cause analysis engine uses event survival times and gradual deletion of events to improve analysis accuracy and reduce the number of required calculations. Certainty factors of relevant rules are recalculated every time notification of an event is received. The calculation results are held in a rule memory in the analysis engine. Each event has a survival time, and when the time has expired, that event is deleted from the rule memory. Events held in the rule memory can be deleted without affecting other events held in the rule memory. The analysis engine can then re-calculate the certainty factor of each rule by only performing the re-calculation with respect to affected rules that are related with the deleted event. The calculation cost can be reduced because analysis engine processes events incrementally or decrementally.

Abstract: A technique determines which configuration change(s) caused an application invocation failure of a computer application without the need for a knowledge database. To determine which configuration change is the most likely cause, the cause analysis program checks other computers that have experienced the same configuration changes. The cause analysis program checks and counts the application invocation results before and after each configuration change is done. If the same configuration changes are found in the other computers, the program checks whether each configuration change caused or cured the same problem in that computer. The program counts the similar cases for all of the computers. Subsequently, the program calculates the ratio of those instances involving a change from success to failure and the ratio of those instances involving a change from failure to success out of all instances for each configuration change.

Abstract: A root cause analysis engine uses event survival times and gradual deletion of events to improve analysis accuracy and reduce the number of required calculations. Certainty factors of relevant rules are recalculated every time notification of an event is received. The calculation results are held in a rule memory in the analysis engine. Each event has a survival time, and when the time has expired, that event is deleted from the rule memory. Events held in the rule memory can be deleted without affecting other events held in the rule memory. The analysis engine can then re-calculate the certainty factor of each rule by only performing the re-calculation with respect to affected rules that are related with the deleted event. The calculation cost can be reduced because analysis engine processes events incrementally or decrementally.

Abstract: A root cause analysis engine uses event survival times and gradual deletion of events to improve analysis accuracy and reduce the number of required calculations. Certainty factors of relevant rules are recalculated every time notification of an event is received. The calculation results are held in a rule memory in the analysis engine. Each event has a survival time, and when the time has expired, that event is deleted from the rule memory. Events held in the rule memory can be deleted without affecting other events held in the rule memory. The analysis engine can then re-calculate the certainty factor of each rule by only performing the re-calculation with respect to affected rules that are related with the deleted event. The calculation cost can be reduced because analysis engine processes events incrementally or decrementally.

Abstract: A root cause analysis engine uses event survival times and gradual deletion of events to improve analysis accuracy and reduce the number of required calculations. Certainty factors of relevant rules are recalculated every time notification of an event is received. The calculation results are held in a rule memory in the analysis engine. Each event has a survival time, and when the time has expired, that event is deleted from the rule memory. Events held in the rule memory can be deleted without affecting other events held in the rule memory. The analysis engine can then re-calculate the certainty factor of each rule by only performing the re-calculation with respect to affected rules that are related with the deleted event. The calculation cost can be reduced because analysis engine processes events incrementally or decrementally.

Abstract: A technique determines which configuration change(s) caused an application invocation failure of a computer application without the need for a knowledge database. To determine which configuration change is the most likely cause, the cause analysis program checks other computers that have experienced the same configuration changes. The cause analysis program checks and counts the application invocation results before and after each configuration change is done. If the same configuration changes are found in the other computers, the program checks whether each configuration change caused or cured the same problem in that computer. The program counts the similar cases for all of the computers. Subsequently, the program calculates the ratio of those instances involving a change from success to failure and the ratio of those instances involving a change from failure to success out of all instances for each configuration change.

Abstract: A root cause analysis engine uses event survival times and gradual deletion of events to improve analysis accuracy and reduce the number of required calculations. Certainty factors of relevant rules are recalculated every time notification of an event is received. The calculation results are held in a rule memory in the analysis engine. Each event has a survival time, and when the time has expired, that event is deleted from the rule memory. Events held in the rule memory can be deleted without affecting other events held in the rule memory. The analysis engine can then re-calculate the certainty factor of each rule by only performing the re-calculation with respect to affected rules that are related with the deleted event. The calculation cost can be reduced because analysis engine processes events incrementally or decrementally.

Abstract: A technique determines which configuration change(s) caused an application invocation failure of a computer application without the need for a knowledge database. To determine which configuration change is the most likely cause, the cause analysis program checks other computers that have experienced the same configuration changes. The cause analysis program checks and counts the application invocation results before and after each configuration change is done. If the same configuration changes are found in the other computers, the program checks whether each configuration change caused or cured the same problem in that computer. The program counts the similar cases for all of the computers. Subsequently, the program calculates the ratio of those instances involving a change from success to failure and the ratio of those instances involving a change from failure to success out of all instances for each configuration change.

Abstract: A root cause analysis engine uses event survival times and gradual deletion of events to improve analysis accuracy and reduce the number of required calculations. Certainty factors of relevant rules are recalculated every time notification of an event is received. The calculation results are held in a rule memory in the analysis engine. Each event has a survival time, and when the time has expired, that event is deleted from the rule memory. Events held in the rule memory can be deleted without affecting other events held in the rule memory. The analysis engine can then re-calculate the certainty factor of each rule by only performing the re-calculation with respect to affected rules that are related with the deleted event. The calculation cost can be reduced because analysis engine processes events incrementally or decrementally.

Abstract: A root cause analysis engine uses event survival times and gradual deletion of events to improve analysis accuracy and reduce the number of required calculations. Certainty factors of relevant rules are recalculated every time notification of an event is received. The calculation results are held in a rule memory in the analysis engine. Each event has a survival time, and when the time has expired, that event is deleted from the rule memory. Events held in the rule memory can be deleted without affecting other events held in the rule memory. The analysis engine can then re-calculate the certainty factor of each rule by only performing the re-calculation with respect to affected rules that are related with the deleted event. The calculation cost can be reduced because analysis engine processes events incrementally or decrementally.

Abstract: A root cause analysis engine uses event durations and gradual deletion of events to improve analysis accuracy and reduce the number of required calculations. Matching ratios of relevant rules are recalculated every time notification of an event is received. The calculation results are held in a rule memory in the analysis engine. Each event has a valid duration, and when the duration has expired, that event is deleted from the rule memory. Events held in the rule memory can be deleted without affecting other events held in the rule memory. The analysis engine can then re-calculate the matching ratio of each rule by only performing the re-calculation with respect to affected rules related to the deleted event. The calculation cost can be reduced because analysis engine processes events incrementally or decrementally. Analysis engine can determine the most possible conclusion even if one or more condition elements were not true.

Abstract: In a computer system that comprises multiple target computers and an analysis computer, one or more first target computers, in which a predetermined application has been installed and invoked, send a log comprising information of multiple configuration changes that have been made prior to invoking the predetermined application to the analysis computer, and the analysis computer receives the log and computes, for each type of configuration change and based on the log, an invocation failure rate which is a percentage at which the invocation of the predetermined application fails subsequent to the configuration change. Then, a second target computer receives, from the analysis computer, first information comprising an invocation failure rate for each type of configuration change related to the predetermined application, and based on the invocation failure rate, displays the type of configuration change that is the cause of the failure of the predetermined application invocation.

Abstract: A technique determines which configuration change(s) caused an application invocation failure of a computer application without the need for a knowledge database. To determine which configuration change is the most likely cause, the cause analysis program (121) checks other computers (102) that have experienced the same configuration changes. The cause analysis program checks and counts the application invocation results before and after each configuration change is done. If the same configuration changes are found in the other computers, the program checks whether each configuration change caused or cured the same problem in that computer. The program counts the similar cases for all of the computers. Subsequently, the program calculates the ratio of those instances involving a change from success to failure and the ratio of those instances involving a change from failure to success out of all instances for each configuration change.

Abstract: A technique determines which configuration change(s) caused an application invocation failure of a computer application without the need for a knowledge database. To determine which configuration change is the most likely cause, the cause analysis program (121) checks other computers (102) that have experienced the same configuration changes. The cause analysis program checks and counts the application invocation results before and after each configuration change is done. If the same configuration changes are found in the other computers, the program checks whether each configuration change caused or cured the same problem in that computer. The program counts the similar cases for all of the computers. Subsequently, the program calculates the ratio of those instances involving a change from success to failure and the ratio of those instances involving a change from failure to success out of all instances for each configuration change.

Abstract: A technique determines which configuration change(s) caused an application invocation failure of a computer application without the need for a knowledge database. To determine which configuration change is the most likely cause, the cause analysis program (121) checks other computers (102) that have experienced the same configuration changes. The cause analysis program checks and counts the application invocation results before and after each configuration change is done. If the same configuration changes are found in the other computers, the program checks whether each configuration change caused or cured the same problem in that computer. The program counts the similar cases for all of the computers. Subsequently, the program calculates the ratio of those instances involving a change from success to failure and the ratio of those instances involving a change from failure to success out of all instances for each configuration change.

Abstract: A root cause analysis engine uses event durations and gradual deletion of events to improve analysis accuracy and reduce the number of required calculations. Matching ratios of relevant rules are recalculated every time notification of an event is received. The calculation results are held in a rule memory in the analysis engine. Each event has a valid duration, and when the duration has expired, that event is deleted from the rule memory. Events held in the rule memory can be deleted without affecting other events held in the rule memory. The analysis engine can then re-calculate the matching ratio of each rule by only performing the re-calculation with respect to affected rules related to the deleted event. The calculation cost can be reduced because analysis engine processes events incrementally or decrementally. Analysis engine can determine the most possible conclusion even if one or more condition elements were not true.

Abstract: A user interface includes a graphical topological representation of an information system. Information is collected regarding connections between switches, storage nodes and computer nodes in the information system. Any sub networks in the system are identified based on the collected information and classified as LANs or SANs. Connections between the various components are determined, and a layout of any identified LANs, computer nodes, SANs, and storage nodes is established for generating the topological representation in the user interface. The graphical topological representation of the information system is displayed in the user interface with the LAN icons, computer node icons, SAN icons and storage node icons laid out in a matrix-like arrangement of columns and rows, such that for LANs, computer nodes, SANs and/or storage nodes that are connected to each other, the corresponding icons are located on or near a same row in the graphical topological representation.

Abstract: In comparison to unnecessary page generation of the prior art, the page generation time according to the current invention is substantially reduced, and the generated page is efficiently accessed. Since in response to at least one of a predetermined set of update events, a page is dynamically generated in advance of a user page request and the dynamically generated page is stored, the current invention allows the efficient page access. The use of the prior art technologies such as proxy servers in combination further improves the cost of transmission of the page to the user according to the current invention.