Method variation for collecting stability data from proprietary systems

• US 7,043,505 B1
• Filed: 01/28/2003
• Issued: 05/09/2006
• Est. Priority Date: 01/28/2003
• Status: Active Grant

• Current Assignee: Unisys Corporation
• Original Assignee: Unisys Corporation
• Inventors: Teague, Tommy Kay, McDonald, Kathryn Ann, Van Der Linden, Diana Love
• Primary Examiner(s): Kindred, Alford W.
• Application Number:
  US10/352,662
• Time in Patent Office: 1,197 Days
• Field of Search: 707 1- 3, 707/200, 719/318
• US Class Current: 1/1
• CPC Class Codes: G06F 11/3612 by runtime analysis performance monitoring G06F11/3466
• CPC Class Codes: G06F 11/3636 by tracing the execution of the program
• CPC Class Codes: Y10S 707/99954 Version management

Abstract

A Cellular Multi-Processor Serve provides partitions having different Operating Systems such as Windows, Unix OS2200 (Unisys), Master Control Program (Unisys) or other Operating Systems, which could be designated as OS-A or OS-B. The present method and system collects and scans availability and reliability information which involve non-windows partitions with respect to planned and unplanned stops, system starts and different categories of error conditions.

Claims

1. In a cellular multi-partitioned server of multiple and different partitioned operating systems which communicate with a Service Processor, a method for collecting event data from first (A) and second (B) specialized partitions comprising the steps of:

(a) reading through an Application Event Log of said Service Processor;

(b) scanning for event entries from said first and second specialized partitions, which cover a selected time-frame period, wherein said first and second specialized partitions respectively include proprietary operating systems designated as Voyager and ClearPath;

(c) parsing of said event entries;

(d) storing said event entries in a local Access database (110).

2. The method of claim 1 wherein step (d) includes the step of:

(d1) establishing an Event Log Data Table from said event entries stored in said local database.

3. The method of claim 1 which further includes the step of:

(e) transmitting, at prescribed intervals, said event entries to a central engineering database.

4. A method for gathering stability information from each partition of a Cellular Multi-Processor (CMP) which is in communication with a Service Processor, wherein unique steps are required to collect event data from certain specialized partitions A and B having operating systems different from Windows Operating Systems, said method comprising the steps of:

(a) checking each partition and Service Processor to see if it includes said specialized partitions A or B, wherein said specialized partitions A and B respectively include proprietary operating systems designated as Voyager and ClearPath;

(b) collecting partition information via scanning about specialized partitions A and B for storage in a collection module;

(c) looping through all system partitions and service processors looking for a Windows Operating System, and if so;

(d) accessing said Windows Operating System with a username password login;

(e) processing the Windows System Event Log into a set of defined System Event Log Classes;

(f) reading the newly-created System Event Log Class into a local database (110);

(g) processing the Windows Application Event Log into a specially-defined Application Event Log Class;

(h) reading said newly-created Application Event Log Class into said local database (110).

5. The method of claim 4 wherein step (b) includes the steps of:

(b1) checking to see if there are more of said specialized partitions to scan through, and if not;

(b2) ending the sequence if no more partitions are available to scan through.

6. The method of claim 5 wherein step (b1) indicates more partitions are available to scan through and then further includes the steps of:

(b1a) for each partition, checking the partition and Service Processor to see if it includes said specialized partitions A and B;

(b1b) collecting the event entries from said specialized partitions A and B for storage in a collection module.

7. In a Cellular Multi-Processing System having multiple and different operating systems communicating with one or more Service Processors, a system for gathering stability information from each partition and Service Process comprising of:

(a) first means for gathering event data from those partitions using Windows Operating (OS) Systems;

(b) second means for gathering event data for non-Windows OS including specialized Operating Systems A and B using information stored on the service processor, wherein said specialized Operating Systems A and B respectively include proprietary operating systems designated as Voyager and ClearPath;

(c) means for collecting said event data from said Windows Operating Systems for placement into a collection module;

(d) means for processing said event data into created logical classes with compatible formats;

(e) means for transmitting said created logical classes to a local database.

8. In a Cellular Multi-Partitioned server of multiple and different partitioned operating systems which communicate with a service processor, a method and program storing event information about specialized partition A (voyager) and B (ClearPath) which are to be scanned, comprising the steps of:

(a) selecting a partition for scanning of events;

(b) determining if the partition is either a specialized A (Voyager) partition or a specialized B (ClearPath) partition, and if so;

(c) storing the Partition Number, Computer Name, System Number and Last Sample into a new Class Object;

(d) adding said Class Object to a partition collection as an internal storage object of the program;

(e) completing steps (a) through (d) for each other ones of said specialized partitions.

9. The method of claim 8 wherein step (b) includes the steps of:

(b1) recognizing the number “

x”

as indicating a specialized A (Voyager) partition, or;

(b2) recognizing the number “

y”

as indicating a specialized B (ClearPath) partition.

10. In a network of multiple partitioned operating systems which communicate with a Service Processor, a system for scanning and collecting Event Information from Windows Event Logs on each Windows operating System (OS) and Service Processor comprising:

(a) means to scan each of said Windows Event Logs in each Windows Operating System and each Service Processor;

(b) means for determining if each Event is associated with a Partition/Service Processor running either a specialized A (Voyager) OS or specialized B (ClearPath) OS, and if so;

(c) means for storing partition information in an internal partition-collection;

(d) means to create an Event Log Data Table in a local database (110) to which events can be added;

(e) means for adding Event information to said Event Log Data Table which falls within a specified time span;

(f) Means for determining if an Event is from a Voyager partition, and if so;

(g) Means for determining whether the selected event is (i) a Start Event or (ii) a Stop Event or (iii) an Initiate Auto Recovery Event.

11. The system of claim 10 wherein means (g) recognizes (i) a start event and from there includes:

(gi) means to write a start record into said local database.

12. The system of claim 10 wherein means (g) recognizes (ii) a stop event and from there includes:

(gii) means to set a pending stop so as to look for an Initiate Auto Recovery (IAR) event.

13. The system of claim 12 where means (g) recognizes (iii) as an Initiate Auto Recovery Event and further includes:

(giii) means to end the sequence and not record this information into the local database (110) since the previous pending stop was handled by assigning a causative reason for said stop.

14. The system of claim 12 wherein step (f) means is not a Voyager but indicates the Event is from a ClearPath OS partition, which then further includes:

(f1) means to determine if said Event was (i) a non-fatal dump or (ii) a fatal dump or (iii) a haltload or a (iv) tracking haltload which then provides a causative reason for said haltload.

15. The system of claim 14 wherein means (fl) recognizes a (i) non-fatal dump and then includes:

(f1ia) means to find there is a STOP time;

(f1ib) means for storing the non-fatal dump event record in said local database (110);

(f1ic) means for storing an unplanned stop Event record in said database (110);

(f1id) means to find a start time and store the start event in said database (110).

16. The system of claim 13 wherein step (giii) of means to assign a causative reason for the stop in a Voyager system includes:

(giiia) means to determine if a stop was pending, and if so;

(giiib) means for determining if the current event is a tracking event;

(giiic) means for determining a cited causative reason for said stop by looking at the IAR event.

17. The system of claim 16 wherein step (giiic) means includes:

(giiic1) means to determine if said stop event is planned or unplanned.

18. The system of claim 17 wherein said means (giiic1) includes:

(giiic1a) means for stor-ing planned/unplanned events in said local database.

19. The system of claim 14 wherein means (f1) recognizes a (ii) fatal dump which further includes:

(f1iia) means to find and record there is a STOP time to said fatal dump;

(f1iib) means for storing the fatal dump event record in said local database.

20. The system of claim 14 wherein said means (f1) recognizes a (iii) haltload and further includes:

(f1iiia) means to find there is a STOP time;

(f1iiib) means for determining the reason for said haltload;

(f1iiic) means for storing the haltload event record in said local database;

(f1iiid) means for determining if there is a start time, and if so;

(f1iiie) storing a start event record in said local database.

21. The system of claim 14 wherein step (f1) recognizes a (iv) tracking haltload and further includes:

(f1iiia) means to find there is a STOP time;

(f1iiib) means for determining reason for said STOP;

(f1iiic) means for storing the reason for a clean shutdown in said local database.