Browse Prior Art Database

Self-deducing problem resolution for applied updates on operating system

IP.com Disclosure Number: IPCOM000015633D
Original Publication Date: 2002-Apr-01
Included in the Prior Art Database: 2003-Jun-20
Document File: 2 page(s) / 41K

Publishing Venue

IBM

Abstract

Disclosed is a program that will allow the operating system to self-diagnose problems encountered as a result of applying new updates on a system. Often system administrators will apply a group of updates, also known as Program Temporary Fixes (PTF's), on a system at one time to get the system up to the latest level. Often the system is functioning properly before applying the updates, but the updates are applied to get extended functionality or as part of good system maintenance to get preventative fixes. Sometimes these applied updates can cause worsened system performance or can introduce new problems on the system. Because almost all updates can be removed after they are put onto the system, the administrator, or technical support can manually debug the problem to determine which of the applied updates is the cause so it can be addressed. However, this can be extremely time consuming to the support personnel who may not be familiar with all changes included with each update, and possible affects of each on the system, resulting in downtime for the system that could cost the customer lots of money. Additionally, when the errors start occurring, there can be no guarantee that a smart system administrator or support person can be found immediately to address the problems. This invention proposes a method to allow the operating system to detect problems, as a result of applied updates, which manifest in system problems by systematic determination of the problem through self-deduction on which updates are potentially causing the problem. The user can tell the system to take a "snapshot" of the typical system behavior (take an average of the daily errors seen. i.e. dropped packets, failed http requests, write retries to disk) and use that as a gauge for the "goodness" of the update to occur. Then, the user applies the updates but does not commit those fixes/updates as a permanent update, i.e. the fixes can be peeled off like an onion layer one fix/update on top of the other. Finally, the system administrator designates in which order (if any) any type of fix "peel-back" will be attempted if an error occurs. Customizable categories can be provided with rankings. For instance, the administrator could create a category called "Printer applications", and give it a ranking that would indicate how removal of updates for the filesets in this category should occur relative to those in other categories. Some rankings could indicate absolute actions, as to indicate that a category of filesets should never be removed, or should always be removed first. In other words, the administrator can say, "Well, this package is always a headache, I want those filesets to come off first if the system is trying to self-diagnose the problem." And, the administrator can specify which filesets never to take off. These would be filesets like kernel updates, which would require a system reboot for it to take effect. Although this requires that the administrator perform some configuration in the initial setup of the program, and possibly when changes occur in the system configuration, it is felt that the benefits of such a program outweigh this inconvenience by providing a way to automate problem determination in complex systems. The basic scenario demonstrating this idea is as follows: An administrator applies

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

Page 1 of 2

Self-deducing problem resolution for applied updates on operating system

Disclosed is a program that will allow the operating system to self-diagnose problems encountered as a result of applying new updates on a system.

Often system administrators will apply a group of updates, also known as Program Temporary Fixes (PTF's), on a system at one time to get the system up to the latest level. Often the system is functioning properly before applying the updates, but the updates are applied to get extended functionality or as part of good system maintenance to get preventative fixes. Sometimes these applied updates can cause worsened system performance or can introduce new problems on the system. Because almost all updates can be removed after they are put onto the system, the administrator, or technical support can manually debug the problem to determine which of the applied updates is the cause so it can be addressed. However, this can be extremely time consuming to the support personnel who may not be familiar with all changes included with each update, and possible affects of each on the system, resulting in downtime for the system that could cost the customer lots of money. Additionally, when the errors start occurring, there can be no guarantee that a smart system administrator or support person can be found immediately to address the problems.

This invention proposes a method to allow the operating system to detect problems, as a result of applied updates, which manifest in system problems by systematic determination of the problem through self-deduction on which updates are potentially causing the problem. The user can tell the system to take a "snapshot" of the typical system behavior (take an average of the daily errors seen. i.e. dropped packets, failed http requests, write retries to disk) and use that as a gauge for the "goodness" of the update to occur. Then, the user applies the updates but does not commit those fixes/updates as a permanent update, i.e. the fixes can be peeled off like an onion layer - one fix/update on top of the other. Finally, the system administrator designates in which order (if any) any type of fix "peel-back" will be attempted if an error occurs. Customizable categories can be provided with rankings. For instance, the administrator could create a category called "Printer applications", and give it a ranking that would indicate how removal of updates for the filesets in this category should occur relative to those in other categories. Some rankings could indicate absolute actions, as to indicate that a category of filesets should never be removed, or should always be removed first. In other words, the administrator can say, "Well, this package is always a headache, I want those filesets to come off first if the system is trying to self-diagnose the problem." And, the administrator can specify which filesets never to take off. These would be filesets like kernel updates, which would require a system...