System for Performing Dump Analysis

1. Field of Use

The present invention relates to knowledge-based systems and, more particularly, to the use of such systems in performing dump analysis.

2. Prior Art

Computer operating systems characteristically use control structures to maintain order in processing. The control structures of an operating system are small collections of related information pertaining to some feature of the operating system.

When a computer system encounters a major problem requiring an interruption of its operation, a physical memory dump is generated for subsequent analysis by system engineers before the system shuts down. Such memory dumps represent the state of the operating system control structures at the time the problem appeared in the system.

Dump analysis is a difficult task. Dumps usually contain a substantial amount of information which encompasses the totality of the operating system structures distributed throughout memory in an unpredictable fashion. Furthermore, since numeric notations (hexadecimal numbers usually) are typically used to represent operating system structures, the interpretation of dumps is generally left to experts for deciphering. Finally, dump analysis requires specific knowledge about operating system structures of specific computer systems that only a few experts possess.

To facilitate the dump analysis task, some system tools have provided facilities for generating a human readable display of memory values in response to user commands. One such system is described in copending U.S. patent application Ser. No. 06/913,157, filed on Sep. 26, 1986. This system provides customized displays from memory or memory dumps with differing internal structure format, by storing a description of the operating system structures in a control structure file which is separate from the program.

In this system, only the control structure file needs to be modified when changes in operating system structures occur. Other system tools provide disassemblers that translate numeric words back into the corresponding assembly language instructions, thus making the dump more human readable or understandable.

While such tools do make dump analysis a less cumbersome task by enabling the display of the operating system structures contained in a dump in a more understandable form, the user is still required to know in advance where to look and what to look for. To the extent that the user does not know where a specific structure is located, the user must browse or search through the operating system structures. This requires additional time and a certain difficulty. Also, even with a good display capability, users still must be able to recognize that they have found the desired information when they see it.

Accordingly, it is a primary object of the present invention to provide a system which automates the analysis of memory dumps.

It is a further object to provide a system which minimizes the amount of time and knowledge required to locate the symptom of a problem resulting in a dump.

The above and other objects of the present invention are achieved by a preferred embodiment of system which includes at least one remotely located host system and a local expert system connected through a communications link. The host system has storage for one or more memory dumps and a retrieval module. The expert system includes knowledge representation and control modules.

The expert system control module includes a knowledge base and an inference processing unit. The knowledge base stores descriptive information representative of different objects and rulesets linked to the objects so that the inference processing unit can interpret the rulesets and derive conclusions using a premise-conclusion if-then form of reasoning. The objects include a number of control objects, each object described by a frame comprising a plurality of slots containing information representing an attribute of that object or a relationship between the object and another object.

In the preferred embodiment, the control objects perform such operations as accessing memory dump information from the host system, creating instances of data structures using retrieved memory dump information and control structures stored in the knowledge base, writing files in the expert system, controlling the firing of rulesets contained in the knowledge base and looking up known problems. The data structures stored in the knowledge base correspond to the operating system control structures includable within each version of each operating system used with each different model of computer system producing memory dumps on which the system of the present invention is used to perform analysis. Different rulesets and subsets correspond to different tasks or major problems symptoms performed by the control module.

In operation, the retrieval module receives specific instructions from the expert system to access a memory dump, retrieves a given amount of information at a predetermined location in the memory dump, formats this information, and returns it to the local expert system.

The knowledge representation module accepts a request from the control module and searches the knowledge base for an instance of a control structure that matches the request. In the event such a structure has been created, the knowledge representation module simply returns parts of or the whole structure in response to the request. Alternatively, when the instance of the control structure does not exist in the knowledge base, the knowledge representation module then transfers control to a host control object which transfers the request to the host system retrieval module.

The retrieval module responds to the request by returning to the knowledge representation module, a series of values as described above. The knowledge representation module retrieves the corresponding operating system control structure from the knowledge base, fills this control structure with the actual values received, and links this updated structure to the ones already present in the knowledge base of the expert system. Then, it returns parts of or the whole control structure to the control module in response to the original request.

The control module makes assumptions based on the information contained in the control structures received from the knowledge representation module, makes requests for other operating control structure and derives conclusions about a given problem by invoking different rulesets as a function of the major problem symptom, after determining the dump information is valid. That is, the control module performs a series of tasks using rulesets and subrulesets which include checking the validity of the memory dump and determining whether a particular major problem symptom was caused by a discernable hardware error. Once a major problem symptom is detected, control is handed over to the ruleset designed to process the symptom.

According to the present invention, the control module of the expert system of the preferred embodiment includes a batch memory dump capability for automatically processing a large number of memory dumps according to specific criteria. Such criteria define the handling of each dump listed within a batch file relative to load, save and run operations. For example, the expert system can be programmed to save those portions of each dump received from the host system, clear each previously loaded dump or overwrite a previous diagnosis with a new diagnosis when performed on a previously processed memory dump.

From the above, it is seen that the system of the present invention can be used to completely automate dump analysis. The system of the present invention reduces the amount of data to be considered for analysis to that which is relevant to the problem at hand. The control module determines which data is relevant and which is to be retrieved next from a dump on the basis of the data retrieved previously.

The system of the present invention includes the capability of generating explanatory reports documenting the analysis as it is performed. This reduces the amount of knowledge required to perform dump analysis when human intervention can not be avoided.

Also, the system of the present invention provides a knowledge base of all operating system structures and is thus enabled to support all versions of the operating system control structures, a by-product of using an object-oriented paradigm in the knowledge representation module.

Further, the system of the preferred embodiment also includes a facility that updates a known problem file, a database of all dumps previously analyzed, which can be used for comparing the current problem to the ones stored in this known problem file to attempt to find a similar problem that has already been solved, thus avoiding solving the same problem twice.

The novel features which are believed to be characteristic of the invention both as to its organization and method of operation, together with further objects and advantages, will be better understood from the description in the following section when considered in connection with the accompanying drawings described in this section. It is to be expressly understood, however, that each of the drawings is given for the purpose of illustration only and is not intended as a definition of the limits of the present invention.

FIG. 1 is a block diagram of a system which incorporates the principles of the invention.

FIG. 2 shows in block diagram form, the major components included in the system of FIG. 2, according to the present invention.

FIG. 3 shows in greater detail, the organization of the control module of FIG. 2, according to the principles of the present invention.

FIG. 4 is an extract of a memory dump applied as an input to the retrieval module of FIG. 2.

FIG. 5 is a diagram illustrating the hierarchical organization of the operating system control structures contained within a specific memory dump.

FIG. 6 shows in greater detail, an example of the internal object representation of a specific operating system control structure created by the knowledge representation module, according to the present invention.

FIG. 7 shows in greater detail, the organization and operation of the control module of FIG. 2.

FIG. 8 is a script of a dump analysis session on a sample memory dump used in describing the operation of the system of FIG. 1.

FIGS. 9 through 14 show in greater detail, the organization and operation of different modules of FIG. 7.

FIGS. 15 through 17e are used to explain the operation of the system of FIG. 1.

FIG. 1 shows the system of the embodiment of the present invention. As shown, the system 10 includes a remotely located host computer system 10-1 and a local computer system 10-2 interconnected to exchange information through a standard communications link 10-4, such as a telephone network, local area network (LAN) or direct line. The host computer system 10-1 includes a host processor 10-10 in which the retrieval module 10-100 is resident, external storage 10-12, such as disk storage on which one or more memory dumps reside, and a terminal controller 10-14 which serves as the interface to communications link 10-4. The controller 10-14 can correspond to a LAN controller, communications controller or similar device. The host computer system 10-1 can be considered conventional in design and may, for example, take the form of a DPS6000 minicomputer system, manufactured by Bull HN Information Systems Inc.

The local computer system 10-2 in the simplest form can be implemented using a conventional personal computer. It can also take the form of a workstation or another minicomputer system. As shown, system 10-2 includes a processor 10-20 which contains the components of an expert system 10-200 constructed according to the principles of the present invention for automating dump analysis. Processor 10-20 couples to a cathode ray tube (CRT) display unit 10-22 through which commands or user selections can be entered via a keyboard 10-25.

The processor 10-20 also couples to external storage 10-24, such as a disk device, from which the components which make up the expert system, are loaded into the memory of processor 10-20 as required. For a workstation, minicomputer system, or personal computer having a large main memory storage, the entire expert system will remain resident thereby enhancing system performance. As shown, system 10-2 further includes a printer 10-26 which can be used to provide a permanent record or listing of rules and explanatory data according to the present invention. In its simplest form, processor 10-20 connects to communications link 10-4 through a terminal emulator 10-28 via a standard modem which enables the exchange of information according to a particular communications protocol such as KERMIT.

FIG. 2 shows in greater detail, the major components of retrieval module 10-100 and expert system 10-200. It is seen that retrieval module 10-100 includes a retrieval utility program module 10-102 and a host communications module 10-104. The retrieval utility program module 10-102, in response to requests received from host communications module 10-104, retrieves specific amounts of data from a specific memory dump stored on external storage 10-12. Module 10-102 returns the requested data to module 10-104 which it transfers to the expert system 10-200 via communications link 10-4.

As shown in FIG. 2, expert system 10-200 comprises a control module 10-202 and knowledge representation module 10-222. The control module 10-202 includes an inference engine 10-204 and a knowledge base 10-206. Inference engine 10-204 includes a rule interpreter 10-204a and a procedural language or LISP program interpreter 10-204b. Knowledge base 10-206 includes a number of operating system objects 10-206a and a number of rulesets 10-206b. The organization of these objects are shown in greater detail in FIG. 3.

The control module 10-202 is coupled to communicate with user/operating system interface 10-22 and with knowledge representation module 10-222. As mentioned previously, the control module 10-202 includes a batch capability for automatically processing a large number of memory dumps according to specific criteria.

In those cases where there is a requirement for interaction between expert system 10-200 and an end user, such interaction takes place through interface 10-22. The end user interface 10-22 has the dual function of presenting information through consultations which include question and answering sessions, help giving interchanges and error indications through windows, menus and prompts and of accepting end user responses. In addition, the end user interface 10-22 may include a display mode component which enables the end user to browse through the operating system structures generated by the automated diagnosis process and currently represented in the system. This display mode also allows an end user to call on the knowledge representation and retrieval modules to retrieve, create, and browse through operating system structures that were not present in the system originally. Finally, the display mode allows the user to follow pointers to operating system structures to display these operating system structures by positioning the cursor on the field of an operating system structure that points to the one that the end user wants to display and pressing a single keyboard key.

As shown, knowledge representation module 10-222 communicates with control module 10-202 to process requests for specific operating system objects contained in the memory dump being analyzed and for known problem file information stored in external storage 10-24. The knowledge representation module 10-222 utilizes information in the form of facts 10-222a in processing requests as explained herein.

The organization of knowledge base 10-206 is shown in greater detail in FIG. 3. By way of background, in an expert system, knowledge about the domain of application is represented in the knowledge base by facts and rules. Accordingly, the knowledge base 10-206 of the preferred embodiment of the present invention is composed by facts 10-222a and rules 10-206b as indicated in FIG. 2.

The facts 10-222a are commonly derived from a frame-based system. As well known, a frame system is a network of frames and relations, corresponding to the nodes and links of a mathematical graph. Frame systems are organized in a hierarchy in which the high-level frames represent general concepts and the lower frames represent more specific concepts. At the lowest levels, the frames represent instances of those concepts. The concept at each frame is defined by a collection of attributes or properties which can have values and, in this respect, the frames and attributes in a frame system are comparable to the records and fields in a database system. Each attribute can have a descriptor associated with it to define the constraints on the values the attribute accepts. Each attribute can also have procedures or programs called daemons attached to it which are executed when the value of the attribute is modified. In such a system, a frame can inherit the attributes or properties of higher level frames.

The preferred embodiment uses a frame-type representation in an object-oriented organization in which the frames represent objects. More specifically, the frames representing general concepts are called classes and those representing specific occurrences of a concept are referred to as instances. In this context, attributes are termed slots, and slot inheritance, descriptors, and procedural attachment take place just as they did in the frame system. In object-oriented systems, however, objects communicate with one another by sending and receiving messages. When an object receives a message, it consults its predefined answers for messages to decide on hat action to take. These answers can be stored directly with the object or inherited from a higher level object somewhere in the network hierarchy. Usually, the action involves triggering some rules, executing procedural code, or sending new messages to other objects in the system.

Within the object paradigm, facts can be explicitly stated or automatically generated from objects. Facts are typically represented as logical expressions, relations, or assertions constituted of operands, atoms, and values. For example, an explicit fact could be represented by the triplet "John is 21" in which "John" is an atom, "is" is an operand, and "18" is a value. An implicit fact generated from an object could be represented by the triplet "John age 21", in which "John" would be an instance, "age" a slot of this instance, and "21" the value of this slot.

The second way in which knowledge is represented in the knowledge base 10-206 is through rules 10-206b. Rules take the form of a premise-conclusion of the form IF conditions THEN actions. Conditions are also called antecedents and actions are termed consequents. Antecedents and consequents consist of a series of patterns. A pattern is a generalization of a fact in that it can be a regular fact, or it may contain variables. Given this definition, one pattern in a rule can match a series of facts in the knowledge base. For example, the pattern represented by the triplet "John is ?age", where "?age" is a variable, would match any fact represented by the triplet containing "John", "s", and an integer in sequence.

Rule interpreter 10-204a interprets rules, matches them with facts, and draws conclusions from this knowledge. Evaluation starts with the data or set of facts corresponding to a specific problem currently in the knowledge base, which is then matched with the antecedents in each of the relevant rules to determine the applicability of each rule to the current situation.

In order to carry out this evaluation process, inference engine 10-204 compares the antecedents of the rules with the facts currently present in the knowledge base. When each pattern of the antecedent of a rule matches with the facts currently in the knowledge base, the patterns in the consequents of the rule are instantiated by propagation. That is, the variables in the patterns of the consequents take the values of the corresponding variables in the patterns of the antecedents, and the actions specified in the consequents of that rule are then executed. When this happens, the rule is said to fire or execute.

Usually, the inference engine 10-204 fires the first rules whose antecedents matches. However, control can be exerted on the firing process in many ways. For example, in the preferred embodiment, the rules are grouped into rulesets. In this context, the inference engine 10-204 only operates on the rules of one ruleset at a time, transferring control back and forth between rulesets when necessary. Furthermore, rules within a ruleset can be ordered for consideration by the inference engine using priorities. At a higher level, hierarchies of rulesets are used to organize, modularize, and control the order of ruleset execution.

The action that is executed when a rule fires may modify the set of facts in the knowledge base, for example, by adding a new fact, and thus cause the firing of other rules. The matching of the antecedents of rules to facts produces inference chains which indicate in what order the system used the rules to reach a conclusion. Inference chains can be displayed or recorded to help explain how a system reached its conclusions. Certainty factors can be associated with the rules. Such certainty factors can be combined according to predetermined formulas to assert the certainty of a conclusion. In this way, the certainty of a conclusion resulting from an inference chain is computed as a function of the certainties of the rules composing the inference chain, and certainty justification can become a part of the explanation of how a system reached its conclusions.

The interpreter 10-204 interprets the procedural statements embedded in the knowledge base rules and facts. The interpreter 10-204b also operates to execute subroutines required to carry out system operations (e.g. I/O, computations, etc.). In addition, interpreter 10-204b handles the interpretation of the programs called daemons that can be attached to various slots in an object using the mechanism referred to above as procedural attachment. Similarly, the program interpreter handles the programs called handlers which can be associated with the objects themselves. A handler program is a program whose sole function is to control a particular input, output or storage device, a file or an interrupt facility. The program interpreter 10-204b is also used to evaluate code resulting from the combination of the above methods when rulesets or rules containing procedural code are procedurally attached to slots or objects.

For the purpose of the present invention, inference engine 10-204 can be considered conventional in design and operate in the fashion described above. For example, it may be constructed similar to the inference engine included in the LOOPS system developed by Xerox corporation or the GoldWorks system developed by Goldhill Inc.

FIG. 3 illustrates the organization of objects within knowledge base 10-206. Overall, system control is carried out through seven separate control elements 302-1 through 302-7. As mentioned, these control elements are objects represented as frames which have a set of handlers. Messages are sent to these control elements during dump analysis. As indicated in FIG. 3, these control elements perform such functions as creating objects (i.e., object control 302-3), accessing information from a host memory dump (i.e., host control 302-6), accessing files on the local system (i.e., local control 302-1), generating explanations (i.e., explanation control 302-7), controlling the firing of rules (i.e., rule control 302-4), looking up known problems (i.e., known problem control 302-2) and in the case of a user interface for displaying menus and windows (i.e., display control 302-5).

As described herein, rule control 302-4 enables batch processing of memory dumps, thereby extending the level of automation.

As shown in FIG. 3, object control 302-3 creates objects by accessing classes of structures through an object 304-3 called data structure. Through this object, the system can access any operating system control structure for any version of a given operating system running on certain models of the computer systems which produce the memory dumps being analyzed. The control structures are organized into four basic classes. These include objects 305-1 through 305-5. The tables control structure 305-1 provides a number of tables, one of which is a code table object 306-1. The code table object 306-1 provides a list of codes and their associated values. One table is the reboot reason code table which gives English descriptions of reboot reason codes utilized by the different computer system models. The table corresponds to object 307-1.

The second class of control structure is a basic structure such as a hardware dedicated memory (HDM) structure and system control block (SCB) structure which are represented by objects 305-3 and 305-5. In the models of computer systems which produce dumps, there can be up to four processors, each is represented by a different HDM shown as objects HDM0 through HDM3, labeled 306-4 through 306-7 in FIG. 3. Also, since there is only one system control block, it is represented by object SCB1 labeled 306-9.

The third class of control structure is a queue type structure representative of a hardware resource which is organized into pools wherein each structure points in the pool until the end of the queue is reached. In the particular models of computer systems, the type of resource includes trap save areas (TSAs) and task control blocks (TCBs).

In FIG. 3, the TSA and TCB resources are shown as objects 306-2 and 306-3 labeled as TSA and TCB, respectively. Since the TSA and TCB resources are generated as a consequence of system operation, there is no minimum number of these resources that are required to be resident in a dump. Therefore, none are shown in FIG. 3 with the exception of object 307-2 shown in shaded form. As explained herein, this represents an instance of the object 306-2 which is generated by the knowledge representation module according to the teachings of the present invention.

The last class of data structures are indicator words 305-4, each of which is a hexadecimal word wherein each bit indicates whether certain functionality (hardware or software) is present within a given computer system model, or whether certain states exist in the computer system model or whether the structure is of a certain type. Included in this class are the indicator words contained in the system control block. These indicator words are represented by objects 306-7 through 306-10 labeled SCBn1 through SCBn4 in FIG. 3. Obviously, knowledge base 10-206 includes other objects representative of the other possible resources which can be found distributed in an unpredictable manner throughout a memory dump.

For further information concerning the types of operating system control structures reference can be made to the reference patent application and to a publication entitled "GCOS6 MOD400 and HVS6 PLUS Operating Systems Data Structures", copyright 1986, under number LP484.

Before describing the operation of the system of FIG. 1, the extent of the level of automation achievable by the expert system of the present invention will first be described. FIG. 16a illustrates the operations performed by control module 10-202 on a single memory dump. For ease of discussion, these operations are described through the use of menus. As shown, block 16a-1 carries out the operations of specifying the memory dump, verifying that the memory dump specified is indeed a file of the proper type, and opening the memory dump file for reading.

For example, as shown in FIG. 16b, the specification of the memory dump is carried out by the system obtaining the number designation (STAR) of the memory dump to be analyzed. The system checks its files to determine if it has previously processed the same memory dump. If it has, it then determines whether the new diagnosis should overwrite the existing diagnosis as illustrated in FIG. 16c.

Up to this time, the system has done no processing of the memory dump until it obtains the pathname of the memory dump file from which portions will be transferred from the host system to be analyzed. This action is graphically illustrated in FIG. 16d.

Next, the system performs the dump analysis as described in FIGS. 7 through 14 and illustrated in block 16a-2 of FIG. 16a.

Then, the system provides for saving the results of the analysis in the known problem file. This action is illustrated in FIG. 16e. Obviously, this operation will only be used when the system allows human intervention.

Finally, block 16a-3 performs the operation of clearing the expert system's knowledge base of dump specific operating system control structure instances before attempting to load and analyze another memory dump as a function of the previously specified criteria.

FIG. 17a illustrates the sequence of operations for batch operation in which the operations of FIG. 16a have been automated so as to enable the specification of a substantial number of dumps which are to be diagnosed in sequence. Block 17a-1 is a generalization of block 16a-1 in which the control module, loops to create a list of all memory dumps which are to be analyzed. Block 17a-2 as shown, performs the analysis on the first dump on the list and thus can be viewed as the functional equivalent of block 16a-2. Once the analysis is completed, block 17a-3 saves the results of the analysis in the known problem file (KPF). Block 17a-4 which corresponds functionally to block 16a-3, clears the knowledge base 10-206. Control is then returned to block 17a-2 to analyze the next dump in the list. The sequence of operations is then repeated until the entire list of memory dumps to be analyzed is exhausted. FIGS. 17b through 17e illustrate the type of specific criteria the system uses in carrying out the operations of FIG. 17a. The list of memory dumps to be analyzed is generated in block 17a-1 either by an interactive loop in which a user enters all of the dump files to be processed in (i.e. FIGS. 17b-17e) or by monitoring the remotely located host system for receipt of a request specifying a memory dump to be analyzed. In this second case, there can be a plurality of different remotely located host systems generating requests to the local expert system via link 10-4 for memory dumps to be analyzed. In such cases if the local system is ready, the request will be processed immediately. Otherwise, the request will be placed as an entry in the list of memory dumps to be analyzed which represents a queue or waiting list of requests. When the expert system completes its current request, it immediately starts processing the next request from the list. This process can be carried out ad infinitum should new requests arrive at about the same time that it takes the expert system to process a request.

The operation of the various major components of the system of FIG. 1 will now be described with reference to FIGS. 1 through 7.

As mentioned previously, the retrieval utility module 10-102 of FIG. 2 receives specific instructions from the local system to access a memory dump in the remotely located host system 10-1, retrieve a given amount of information starting at a predetermined location in the dump, format this information, and return it to the local expert system 10-2.

In the preferred embodiment of the present invention, requests for dump data are encoded in the LISP programming language by the expert system and transferred as LISP strings over communications link 10-4 through emulator 10-28 according to the KERMIT protocol. Such requests are received by the retrieval module 10-100 resident on host system 10-1. Typical requests are to open or close a memory dump, retrieve a given amount of bytes or words starting at a specific offset in a memory dump, retrieve a physical or virtual address from a memory dump, retrieve a pointer value from a memory dump, trigger debugging features, and retrieve a command line from a user, execute the command on the host system, and return the results of the command.

In brief, most requests include some form of retrieval of data from a memory dump. Retrieving data from a memory dump requires to specify the start address of the data to be retrieved and the number of bytes or words to be retrieved. Data retrieval is not always straightforward, since some addresses may need to be converted from virtual into physical address format. Furthermore, data retrieval from memory dumps is usually complicated by the fact that such files are not simple sequential text files consisting of ASCII characters, but are organized as a series of records of a given size (usually 256 or 1024 bytes), from which requested data must be extracted. Thus, retrieval module 10-100 has been designed to take these factors into account.

FIG. 4 depicts an extract of the contents of a memory dump. As can be seen, a typical memory dump contains a series of addresses, each containing up to eight hexadecimal digits. One request on the memory dump in FIG. 4 could be represented as "1 0000 10", which means retrieve 10 hexadecimal words (or 16 decimal words) from the current dump starting at address 0000. Such A request would return the following list of data when retrieved from the memory dump of FIG. 4: "83CO FFFE 006F E073 83CO 0608 FFFF FFFF FFFF FFFF 0000 0000 0000 0000 0000 0000". More generally, request presented as an input to the retrieval module 10-100 can be viewed as a function call with certain parameters. The retrieval module accepts the following types of request as inputs:

1. EXIT without parameters;

2. SENDPHYS with a start address as a hexadecimal number and a length also as a hexadecimal number to retrieve a physical address from a dump;

3. SENVIRT with a start address, a length, and a map (called dsbra, and used in computing a physical address from a virtual one) all three as hexadecimal numbers, to retrieve a virtual address from a dump;

4. OPENFILE with a filename as a symbol and a record size as an integer, to open a memory dump for retrieval;

5. TOGGLEDG without arguments, to create a toggle that turns debugging print statements on and off;

6. TRANSLATE with an address and a map both as hexadecimal numbers, to translate virtual addresses to physical ones;

7. HVSESC with a command line as a string, to performs a host command;

8. SENDLDBU with an address as a hexadecimal number, to get from a dump the list of all the loaded bound units (modules) in the system at the time of the dump;

9. OPENTRAC with a file name as a symbol, to open a trace file to obtain a debugging script;

10. WRITTRAC with a text line as a string, to write a text line in a trace file for debugging purposes;

11. CLOSTRAC without argument, to close a trace file;

12. CLOSFILE without argument, to close a dump file;

13. UNASVIRT with a start address and a length both as hexadecimal numbers, to get a virtual instruction from a dump and disassemble it.

The output of the retrieval module is almost always either a list of the instructions that were retrieved by request, or of the assembly code for such instructions in the case of the UNASVIRT command. A string is returned instead of a list when the retrieval module encounters an error.

In any case, once a string, such as the one in the above example is retrieved from a memory dump, it is returned by the retrieval module to the local expert system 10-2 and is transformed into a LISP list or string for use by the expert system. For the purposes of the present invention, the above conversion can be considered to be performed in a conventional manner.

The knowledge representation module 10-222 accepts requests from the control module 10-202 of FIG. 2 for a control structure contained in the memory dump being processed and searches the knowledge base 10-206 for one that matches the request. In the event such a structure is already present in the knowledge base, the knowledge representation module 10-222 simply returns parts of or the whole control structure in response to the request. Alternatively, when the control structure does not exist in the knowledge base, the knowledge representation module 10-222 then transfers control to the retrieval module 10-100 passing along the request received from control module 10-202. The retrieval module 10-100 responds to the request by returning a series of values as a LISP string as described above. The knowledge representation module 10-222 retrieves the corresponding operating system control structure from the knowledge base, fills this control structure with the actual values received, and links this updated structure to the ones already stored in the knowledge base.

Once the knowledge representation module 10-222 is in possession of an "instantiated control structure," it returns parts of or the whole structure to the control module in response to the original request. FIG. 5 illustrates an overview of the hierarchy of operating system structures stored in the memory dump of FIG. 4. FIG. 6 shows a Hardware Dedicated Memory, control structure containing the corresponding values from the dump.

As explained earlier, the control module 10-202 calls on the knowledge representation module 10-222 of FIG. 2 with a request for data representing an operating system structure. When the request is answered by the knowledge representation module 10-222 as described above, the control module 10-202 makes assumptions based on the information contained in the structure received, makes requests for other operating structures, displays information about them to the user, and derives conclusions about the problem at hand.

FIG. 7 is a block diagram that illustrates the organization and operation of the control module 10-202 of FIG. 2. Before discussing the contents of FIG. 7, it is useful to point out that each computer system model whose memory dumps are being analyzed divides the jobs that want to run into program groups (as is conventional), each group consisting of a number of tasks. Each of the operating systems of the given computer system models provides a number of active levels (priority levels) at which the tasks can run. The program groups are assigned certain priority levels and, once a program group is enabled, the tasks or programs in this group are enabled to use the system resources to execute such tasks. These levels are associated with the interrupts in the system. The task or program being executed may be interrupted by an event assigned a priority level greater than the level of the current task or program being executed.

In order to be executed, a task must change its current level from the group's to the level at which tasks can be executed. Once a task has completed its execution, it changes its level back to the level of that task's group, and another task, possibly from another group, is allowed to execute at the level just freed. The operating system first runs tasks located on the lowest level, then tasks located at the next higher level, and so on until it reaches tasks at the highest level. Due to group priorities, tasks awaiting execution may continuously replace the task that finished executing at a given level and tasks located at higher levels may never be allocated system resources to execute unless pre-emption is used to alter the group priorities.

During such operations, information relating to levels, interrupts, etc. are stored in the different operating system control structures. In general, the control module 10-202 will attempt to locate the group and task that caused the problem which forced the computer system to execute a dump.

As shown in FIG. 7, the control module 10-202 is organized from a ruleset viewpoint into four major components. These are a validity module 107-1, an information module 107-2, a diagnosis module 107-3, ad a search module 107-4. The validity module 107-1 determines if the dump and the control structures contained within the dump are valid so as to be useable for analysis and diagnosis.

The information module 107-2 operates to generate general information about the memory dump that is used in generating explanations which are saved in the known problem file, and in carrying out the rest of the diagnosis in terms of selecting, among the major symptoms, the one that caused the problem. As mentioned, the major symptoms represent the basic hardware states or conditions which a computer system can assume. In the preferred embodiment, there are three major symptoms which correspond to the following conditions:

1. A Halt--A condition wherein the operating system detected a serious problem and brought the system to a halt;

2. Idle State--A condition wherein the operating system was idle when it should have been processing user requests which resulted in the dump being performed followed by a system reboot operation;

3. Other--A condition wherein the operating system detected a problem which was neither a Halt nor an Idle State.

Once module 107-2 diagnoses the major symptom it hands over control to diagnosis module 107-3. The diagnosis module 107-3 includes a number of submodules containing rulesets designed to specifically find the cause of a problem based upon a particular major symptom. Each ruleset is divided into a number of rule subsets which correspond to subsymptoms of the major symptom. As seen from FIG. 7, the subrulesets include submodules 107-31, 107-32 and 107-33 which are shown in greater detail in FIGS. 9 through 14.

When diagnosis module 107-3 is unable to identify the problem, it passes control to search module 107-4. This module contains rulesets 107-41 and 107-42 for searching for a problem in all of the active tasks and then in the newest task within each program group. When a problem is found, diagnosis module 107-3 passes control to a known problem file module which includes rulesets for searching the known problem file for a similar problem previously diagnosed and for which a solution already exists.

As seen from FIG. 7, in locating the problem the control module first calls Block 107-1 to check the validity of the main operating system structures contained in the memory dump. Block 107-11 checks the validity of the Hardware Dedicated Memory (HDM). Block 107-12 checks the validity of the System Control Block (SCB). Block 107-13 checks the validity of the memory dump by comparing its size to that of the high memory address of the operating system. Since a dump represents a frozen picture of the system at the time of the crash, the size of a dump should be equal to the highest address of the operating system.

If some of the validity checks fail, module 107-1 generates the corresponding error message to the system or user and attempts to continue. Once validity module 107-1 completes all of the validity checks, it passes control to information module 107-2 which displays dump information to the user.

The control sequencing inside of module 107-2 passes sequentially through submodules 107-21 through 107-211. Submodule 107-21 finds the type, release, and update of the system being diagnosed to locate the proper system programs that may need to be examined and to determine if the computer system model that created the dump needs an upgrade because a problem that appeared in an old version may have been fixed by a later version.

Submodule 107-22 determines the type of memory management unit currently being used by the operating system so that the rest of the control module will be able to use the proper algorithm to properly translate virtual addresses into physical addresses.

Module 107-23 retrieves the system boot and dump times and compares them in order to determine if the computer system crashed during or after the boot, each case requiring different recovery procedures. Since the operating system being analyzed can have up to four processors (CPUs), and since there is one HDM structure for each CPU, module 107-24 retrieves the other HDMs that may exist in the system. Module 107-25 then determines the major symptom of the problem: Level 2 Halt (L2H), Idle State (IS), or Other (0). This determination is performed by using information from the interrupt activity flag table, located at offset 20 (hexadecimal number) of the HDM shown in FIG. 6. Module 107-26 retrieves the active levels for each CPU, i.e., the levels at which tasks were being executed at the time of the crash.

Module 107-27 retrieves the contents of the register values that were saved immediately prior to the crash since these values will be useful in locating the problem. Module 107-28 then determines the number of Trap Save Areas (TSA) and Internal Request Blocks (IRB) used to see if the operating system ran out of these resources which would explain the crash, thus limiting the analysis to searching for the task or tasks monopolizing all of the system resources.

Module 107-29 determines the Restricted Functionality Indicator (RFI) which is used in some cases to limit the amount of possible sources of the problem. Module 107-210 attempts to find a group (defined by a group control block) in a faulty state, thereby stopping other groups from sending their tasks for execution and thus monopolizing the system. Finally, module 107-211 returns the names of all of the bound units (BU) loaded in the system at the time of the crash. Since these BUs name the programs actually running on the system, they are used to retrieve the code of these programs within the memory dump stored on the host system to locate the specific instruction that caused the machine to halt once the cause of the problem has been reduced to one BU.

Control is then transferred to diagnosis module 107-3. Module 107-3 redirects control to modules 107-31, 107-32, or 107-33 as a function of the major symptom of the problem (i.e., L2H, IS, or 0 condition, respectively). If the symptom is an L2H condition, module 107-31 determines the reboot reason code, the task that caused the L2H, if useful, and sequences to module 107-34 if the determination of the task fails. The organization and operation of module 107-31 are shown in greater detail in FIG. 9.

If the symptom is an IS condition, module 107-32 searches through each system group looking for a task that is waiting for a resource or holding one. It provides resource information for each task, including information indicating if the resource count is high or low. The organization and operation of module 107-32 are shown in greater detail in FIG. 10. As can be seen from FIG. 10, block 10-1 initiates the processing of an IS condition by verifying that the "F switch" of the system group is turned on. This switch indicates that the system attempted to force a L2H condition upon encountering an error. If turned off, this switch indicates that the system has encountered an error and was unable to go to a L2H condition. In such as case, the problem can not be qualified as an IS condition any longer, and the system aborts the processing of the IS condition, passing control to module 107-34 in FIG. 7. When the switch is turned on, block 10-2 proceeds onto the examination of the queue of all system groups and retrieves the first group in this queue. Then, block 10-4 retrieves the newest task running in the group to verify whether this task was idling or not via block 10-6. If errors such as a bad task or group occur during retrieval, blocks 10-3 and 10-5 are called. Block 10-3 causes an exit from the IS condition and redirects control to module 107-34 of FIG. 7 upon encountering a bad group since this prevents block 10-10 from following the chain of all system groups any further. Block 10-5 redirects control to block 10-7 for error reporting when a bad task is encountered. However, processing can subsequently resume with the next group in the queue. When no such errors are encountered and the newest task in the group currently under scrutiny appears to be idling, block 10-8 reports detecting the idle task. Block 10-8 is described in greater detail in FIG. 14.

If the symptom is neither a L2H nor an IS condition, control is transferred to module 107-33 which checks for a hardware failure, a shortage of system resources, or for a system group in an faulty state condition. The organization and operation of module 107-33 are shown in greater detail in FIG. 11. Block 11-1 checks for a hardware failure. If such is the case, the problem is found and processing leaves block 107-33. Otherwise, block 11-2 verifies that the system has not run out of Trap Save Areas (TSA). If a TSA problem exists, block 11-3 retrieves the first active task, calls block 11-4 to find the number of TSAs the task uses, tests if this number is reasonable via block 11-5, and reports the task via block 11-6 if the number appears to be unreasonable. Block 11-7 checks if any active task remains and repeats this process via block 11-8 which fetches the next unprocessed active task. When all active tasks have been processed in this way, control leaves module 107-33 to module 107-34. However, if block 11-2 does not discover a lack of TSAs, block 11-9 is called upon to determine if a group is in a faulty state. If no such group exists, module 107-33 is abandoned for module 107-34. Blocks 11-6 and 11-11 on task reporting are described in more detail in FIG. 13.

Module 107-3 starts to operate from a major symptom, and decomposes this major symptom into subsymptoms. Subsymptoms are more detailed specifications of the problem that can be used to differentiate the current problem from previously diagnosed ones, to classify the current problem as one that has been encountered before, or to report a type of problem for which the system has no solution.

If no problem has been found by module 107-3, control is passed to module 107-4. Otherwise, module 107-4 is bypassed. The organization and operation of module 107-4 are shown in greater detail in FIG. 12. This module searches for a problem in all of the active tasks 107-41 and then in the newest task of each group 107-42. In FIG. 12, blocks 12-1 and 12-2 correspond exactly to modules 107-41 and 107-42 of FIG. 7. The function of block 12-1 is to loop over all active tasks. Block 12-11 retrieves the first active task, which is then reported via block 12-12. Block 12-13 checks for a problem in the task. If a problem is found, the loop is terminated and block 12-1 is exited. Otherwise, the loop continues and block 12-14 tests for the presence of other active tasks, using block 12-15 to fetch the next active task if such a task exists. In all cases, the loop is eventually exited and a check for a problem is performed by block 12-3. If a problem is detected by block 12-1, processing leaves module 107-4. Otherwise, block 12-2 is called upon to search for a problem in the newest task of each system group. The function of block 12-2 is to loop through all system groups. For each such group, block 12-23 fetches the newest task in the group and block 12-25 reports this task (as described in greater detail in FIG. 13). Blocks 12-22 and 12-24 handle bad tasks and groups respectively, using block 12-26 to report task errors. Blocks 12-21, 12-28, and 12-27 perform the initialization, iteration, and termination condition of the loop, respectively. In all cases, control leaves block 107-4 whether or not a problem is detected. Blocks 12-12 and 12-25 on task reporting are described in greater detail in FIG. 13.

When a problem is found, control is passed to module 107-5 which searches a known problem file (KPF) for a similar problem corresponding to a dump which has been previously diagnosed and for which a solution already exists.

During the course of a diagnosis, the problem under scrutiny is specified little by little as the diagnosis progresses. This leads to a description of the problem which includes its major symptom, subsymptoms, and other information pertaining to the problem, such as the reboot reason code for an L2H condition and other such data. This description is then stored in the KPF. When the diagnosis is completed, the only trace of its occurrence is such a description, now stored in the KPF for the duration of the session. This description can be stored permanently if the system or user specifies saving the KPF before terminating a session. After many diagnoses have been run, many problem descriptions exist in the KPF.

When a new diagnosis is run, a new description is created and compared against the ones that exist in the KPF. The search for a known problem thus consists in looking for a match between the current problem and a previously diagnosed problem. The matching is performed using the descriptions for each problem. The data elements that constitute these descriptions have numeric weights associated with them. When a description is being created during a new diagnosis, a weight is associated with each data element of the evolving description. The arithmetic sum of the weights of all the data elements in a description constitutes the weight of the description. When performing matching, module 107-5 creates a "template" for each KPF description and initializes its weight to 0. Then it looks at each data element in the current problem description and attempts to find it in each KPF description. If it finds it, the weight of that data element is added to the weight of the templates of each KPF description in which the data element was found.

When each data element of the current description has been processed as described, module 107-5 is in possession of as many weighted templates as there are KPF problem descriptions. A match between two descriptions is deemed to have occurred if their total weights are within 10% of each other. Accordingly, to determine which templates really constitute a match, module 107-5 compares the weight of the current problem with the weight of each template. Module 107-5 adds the template to the list of matches when the arithmetic difference between the two weights does not exceed 10%. It will be appreciated that various operations can be performed on the KPF. That is, problem descriptions can be added, deleted, displayed, and updated; solutions and comments can be associated with a problem description; searches of the KPF can be requested for a specific problem.

If one or more matches between the current dump and a known problem exist, as tested by module 107-9, they are reported by module 107-8. Whether a match exists or not, if the problem has been found, the control module reports a successful diagnosis via module 107-6. Otherwise, if the problem could not be located, the control module reports a failure via module 107-7. In both cases, the diagnosis is deemed completed and control module operation is terminated.

FIGS. 13 and 14 show in greater detail, the organization and operation of reporting tasks and idle task respectively. These two task reporting modules are utility modules which are called in many places within the other modules of FIG. 7. As shown in FIG. 13, module 13-1 starts by checking if the task to report is really a task. If not, module 13-2 reports an error and control is returned to the caller. Otherwise, a second check is performed by module 13-3 to see if the task has already been reported during a previous call of this module from another module of FIG. 7. If so, control is returned to the caller. Otherwise, a third check for validity is performed by module 13-4 and an error is reported by module 13-2 before returning control to the caller if the task is invalid. However, if the task is valid, module 13-5 displays various task information and initiates TSA processing via module 13-6.

TSA processing consists of a loop over all the TSAs used by the task, retrieving relevant information and looking for a problem. Modules 13-61, 13-66 and 13-65 perform the initialization, iteration, and termination condition operations of the loop, respectively. Module 13-62 is in charge of reporting TSA information. Modules 13-63 and 13-64 test for and report the presence of an error. When all the TSAs of the task have been processed in this way, control leaves module 13-6 and is transferred to module 13-7 which checks if the task is an idle task as detected by module 13-6. If it is, module 13-8 reports the idle task before returning to the caller. Otherwise, no problem is apparent and control returns to the caller. The organization and operation of module 13-8 is shown in greater detail in FIG. 14.

FIG. 14 is a special case of FIG. 13. FIG. 13 illustrates task reporting, while FIG. 14 illustrates the reporting of a particular type of task (i.e. an idle task). Idle task reporting begins with module 14-1 which checks for the reason why a task is idle. A task is idle when it is waiting for a system resource to be freed up for use. Resource usage is controlled by semaphores which insure that only one task can access a resource at a given time. If the task tested by module 14-1 is not waiting for a semaphore, it is deemed not idle and control is returned to the caller. Otherwise, control is passed onto module 14-2 which checks if the semaphore is a valid one. If it is not, module 14-3 reports an error before returning control to the caller. However, if the semaphore is valid, module 14-4 retrieves the resources count for this semaphore. This count reflects the number of tasks that are waiting for the semaphore. Module 14-5 then tests to see if the number of tasks waiting for the semaphore is reasonable. If it is, all is deemed normal with the task and control is returned to the caller. If the number is not reasonable, this is identified as a problem and module 14-6 looks for the task that is holding the resource managed by the semaphore on which tasks including the one under scrutiny are waiting. If the holding task if found, as tested by module 14-7, control is passed to module 14-8 to report the identity of the holding task before returning to the caller. If the holding task is not identified, control is returned to the caller directly. It will be noted that module 14-8 performs normal task reporting as described by FIG. 13. Thus, since the caller for idle task reporting can be the task reporting module, the task and idle task reporting modules can call each other recursively and thus enter a double recursion.

Thus, the modules of FIG. 7 which correspond to rulesets are triggered in a deterministic fashion as described above. However, the specific rules within each ruleset or block may be triggered in a different order depending on the values contained in the specific memory dump under analysis. For instance, the validity checks performed by module 107-1 may be performed in a different order for different memory dumps, depending on the particular values contained in the HDM fields for each memory dump.

The operation of the system of FIG. 1 will now be described in detail with respect to analyzing a sample memory dump which produces the results shown in FIG. 8 based upon examining the operating system control structures contained in the memory dump of FIG. 4 which are represented in more human readable form in FIG. 5.

The output 8-1 of FIG. 8 corresponds to the results obtained by validity module 107-1 of FIG. 7. Outputs 8-2 through 8-10 correspond to the results obtained by information module 107-2. The outputs 8-11 through 8-16 correspond to the results obtained by diagnosis module 107-3. The outputs 8-17 through 8-18 correspond to the results obtained by known problem file module 107-5.

As can be seen from output 8-11, the problem in this case is diagnosed as an L2H condition. This module 107-31 is the only block that gets executed inside of module 107-3. Furthermore, since the problem was located in this example, search module 107-4 is bypassed, and the known problem file module 107-5 is called directly by module 107-3, completing the diagnosis process with a success report being generated by module 107-6 as shown by output 8-19.

During operation, control module 10-202 first calls on validity module 107-1 to perform some validity checks. This is done by the expert system accessing the corresponding ruleset object 304-4 through the ruleset control object 302-4 within the knowledge base 10-206 of FIG. 3. As mentioned, each system model can have from 1 to 4 CPUs, labelled CPU 0 through CPU 3 for which there can be an HDM control structure or object corresponding to every CPU in the system contained in knowledge base 10-206. The HDMs which correspond to CPU 0, 1, 2, and 3 must start at hexadecimal addresses 0, 100, 200, and 300, respectively.

In the manner previously described, the control object 301 calls object control 302-3 requesting the first HDM control structure filled with the corresponding memory dump values corresponding to CPU0 (i.e., instance HDM0). This specific instance HDM0 is shown in FIG. 6. If object control 302-3 detects that this instance is not present in knowledge base 10-206, it sends a request to the knowledge representation module 10-222 of FIG. 2. The system performs the sequence of operations shown in FIG. 15 which results in the HDM0 control structure being stored in knowledge base 10-206 which is indicated by the shaded area representation of object 306-4 in FIG. 3.

Control is returned to validity module 107-11. With reference to FIG. 5, module 107-11 then fetches the HDM's first word at hexadecimal offset 0 and checks its validity by verifying that the value it contains is the hexadecimal number 83C0. Module 107-11 also verifies that the starting address of an HDM is a multiple of hexadecimal 100, does not exceed an address value of hexadecimal 300, in addition to matching the number of CPUs. This is done by comparing the starting address of the HDM and the CPU number. The number of CPUs present in the system is determined by retrieving the SCB control structure from the dump and examining the value at location hexadecimal offset 7D. As seen from FIG. 5, the SCB control structure is located by a pointer located at address hexadecimal offset 18 of the HDM as shown in FIG. 5. Module 107-11 first checks the validity of this pointer before retrieving the SCB control structure from the dump. The SCB pointer is valid only if its value is one of the following hexadecimal numbers: 12E2, 1494, 4E8, 4F0, and 12A2 for different releases and updates of the operating system. At this point, the control module generates message 8-1 of FIG. 8 as the first result of the diagnosis.

Once the validity of the HDM for CPU 0 has been established, module 107-12 performs a similar operation on the SCB control structure. This involves verifying that the SCB starting address is equal to its true address found at hexadecimal offset 18 of the HDM of FIG. 5. It also involves checking that the initial and current times are not ZERO. These two times are obtained from the locations of the SCB structure designated by hexadecimal offsets 48 and 4B. Module 107-12 also verifies that the number of CPUs is not 0 or greater than 4 by testing the contents of the location defined by hexadecimal offset 7D of the SCB. Finally, the module 107-12 performs a check to verify that the Group Control Block (GCB) pointer located at hexadecimal offset 6 of the SCB is not ZERO.

Once the validity of the SCB has been established, control is passed onto module 107-13 which determines the validity of the dump. This operation consists in extracting the high physical memory address at the location of the SCB corresponding to a hexadecimal offset 28 and comparing it to the dump size for equality. If this test is completed successfully, module 107-13 passes control back to module 107-1 which is now completed and redirects control to module 107-2.

Since module 107-1 determined that the main structures of the dump are valid, module 107-2 can now safely gather and display some information about the dump. For this operation, control passes sequentially through modules 107-21 through 107-211. Module 107-21 retrieves the type of system from bits B and C of the CLM front end file index field located at hexadecimal offset 158 of the SCB and generates message 8-2 in FIG. 8. Module 107-22 retrieves information defining the type of memory management unit from bits D and E of the CLM front end file index field and generates message 8-3 in FIG. 8.

Module 107-23 reports the boot and dump times located at hexadecimal offsets 48 and 4B of the SCB and generates message 8-4 in FIG. 8. Module 107-23 also checks that the dump time is greater than the boot time and that the difference between the two times is greater than 5 minutes. If the dump time is smaller than the boot time, the time values can not be relied upon since a dump can not be taken before the machine is booted (turned on or re-initialized), and a message to this effect is generated. However, if the dump time is within 5 minutes of the boot time, the system crashed during booting and initialization and a message is generated stating that the boot procedure should be verified. These messages are shown in FIG. 8 since it is assumed that the dump time is much greater than the boot time in the dump under analysis as indicated in message 8-4.

Module 107-24 retrieves from the dump, the HDMs corresponding to CPUs 1, 2, and 3 as a function of the CPU number contents at hexadecimal address 7D. The HDMs are obtained by performing the sequence of operations shown in FIG. 15. Module 107-24 performs the checks of module 107-11 for each additional HDM. At this point, module 107-25 determines the major symptom: Level 2 Halt (L2H), Idle State (IS), or Other (0). This is done by obtaining and examining the interrupt activity flag bits of a table located at hexadecimal offset 20 of the HDM for CPU 0 shown in FIG. 5. This table contains 64-bit positions representative of the activity of lines 0 through 63. When the level 2 bit position is in an active state, the symptom is an L2H condition, and the control module designates an L2H condition as the major symptom. However, if level 63 bit position is in an active state but bit positions 0 and 2 are not, then the symptom is an IS condition and module 107-25 designates the major symptom. Finally, if there is no L2H or IS symptom detected, then module 107-25 designates " 0" as the major symptom.

Then, module 107-26 translates the interrupt activity flag table values into a human readable form and generates signals for displaying the active levels of the system at the time of the crash. This corresponds to message 8-5 in FIG. 8. This is performed for each CPU in the system. Since FIG. 8 depicts the diagnosis of a mono-CPU system, this operation is performed only once.

At this point, module 107-27 attempts to retrieve the register values that were saved for each CPU just before the crash in the case of an L2H condition. To do this, module 107-27 examines the contents of the HDM location defined by hexadecimal offset 80 to find the task present in the interrupt vector 0 (IVO) (power failure interrupt which is represented by the task control block in FIG. 5). It then looks at the location corresponding to hexadecimal offset -4 of the TCB to obtain the interprocessor communication mailbox structure (ICM). The contents of the location at hexadecimal offset 31 of the ICM is used to locate the Context Save Area (CSA) that contains the saved register values for an L2H condition. These values are then retrieved and displayed as indicated by message 8-6 in FIG. 8.

Module 107-28 attempts to determine the amount of resources that have been used by the system. This is done by extracting the initial, current, and lowest Trap Save Area (TSA) and Internal Request Block (IRB) numbers from hexadecimal offsets BA through BF of the SCB shown in FIG. 5, and comparing these numbers to determine if the current amount of resources is the also the lowest, and if the lowest amount of resources available to the system was sufficient to continue operations. These numbers are contained in message 8-7 in FIG. 8.

Module 107-29 then determines the meaning of the Restricted Functionality Indicator (RFI) values, contained in the location at hexadecimal offset 159 of the SCB, and generates message 8--8 in FIG. 8. Module 107-210 is then called upon to retrieve the Switch Word for the system group control block (SCB) in FIG. 5 and check if the system is in an xstate. This is done by examining the contents of a location called $S at hexadecimal offset 8 of system GCB. Module 107-210 interprets the values of the Switch Word and if these values correspond to an xstate, the problem is deemed found and it is reported. Otherwise, the meaning of the Switch Word values is reported as in message 8-9 in FIG. 8.

Finally, module 107-211 retrieves the list of all the Loaded Bound Units (LDBUs) in the system at the time of the crash and generates a message 8-10 in FIG. 8 in which each BU is displayed along with its start address in hexadecimal notation, and its Software Technical Identifier (STI) which provides information about the nature, release number, and version number of the BU.

This completes processing by module 107-2 which results in control being passed onto module 107-3. Since the major symptom in the case of the example in FIG. 8 was determined to be an L2H condition, control is passed directly to module 107-31 after generating message 8-11. Module 107-31, which is shown in greater detail in FIG. 9, calls module 9-1 to determine the reboot reason code.

Module 9-1 obtains from the location designated as hexadecimal offset 90 of the SCB to find the reboot reason code. It compares this code to the reboot reason code table corresponding to object 307-7 of the knowledge base 10-206 which lists all the possible code with their associated meanings. In the present example, the reboot reason code has an hexadecimal value of 090C, and the associated meaning is "Reboot reason code is 090C=System Task Trp". This meaning is then displayed as message 8-12 in FIG. 8.

Module 9-2 then compares this reboot reason code with the contents of the location designated as hexadecimal offset IA of the CSA of FIG. 5. If the two values are equal, the task found in the C0 register specified at hexadecimal offset 5 of the CSA is the task that caused the L2H condition. However, if test 9-3 determines that the C0 register could not be found, module 107-31 operation is stopped and control is passed to module 107-34 of FIG. 7. If test 9-4 determines that the reboot reason code is "0902" or "0912," which is meaningless since it corresponds to a L2H requested by a human, a message to this effect is generated and control also leaves module 107-31 and is passed to module 107-34.

In the present example, since this is not the case, message 8-13 is generated describing the task that caused the L2H condition. Thus, control is passed to module 9-6 to retrieve the TCB corresponding to the task that caused the L2H condition.

Once the TCB is located, control is passed to module 9-7 which is shown in greater detail in FIG. 13. The tests 13-1 through 13-3 determine that the TCB given to them is indeed a TCB control structure, has never been encountered before. Unless an error string is given to module 9-7 by the test 13-1 will receive a real TCB. Test 13-2 looks up a list of all the TCBs that have already been reported to determine if the current one is a new one. A TCB is valid if the location designated as hexadecimal offset 01 contains the hexadecimal value FFFF. In the present example, since no error messages appear, control is passed to module 13-5. This block consults various TCB offsets to find the values which are to be incorporated to the rest of message 8-13 in FIG. 8.

Control then passes to module 13-6 which retrieves information about the TSAs that are used by the task that caused the L2H condition. The TSA information is retrieved in a manner similar to TCB information and is reported in messages 8-14 through 8-16 in FIG. 8. Control then leaves module 13-6, returns to the caller (i.e., module 9-7) and after failing test 13-7, leaves module 9-7 therefore terminating the operation of module 107-31. Since the problem has been found, test 107-34 is successful, and module 107-4 is bypassed to go directly to module 107-5.

Module 107-5 performs a search of the Known Problem File (KPF) containing all the dumps previously diagnosed, for a problem description that matches the one currently under analysis. Problem descriptions are stored in the KPF as a list of symptoms derived from the explanation contained in FIG. 8. For the present dump, the list of symptoms is the following: ((TYPE-OF-SYSTEM DPS6-PLUS) (MEMORY-MANAGEMENT VMMU) (MAJOR-SYMPTOM LEVEL-2-HALT) (REBOOT-REASON-CODE 2316) (TASK-CAUSED-LEVEL-2-HALT-AT-LEVEL 11) (TASK-ADDRESS 242930) (TASK-GROUP "$S") (TASK-PC 22246) (BOUND-UNIT "Z3EXECUTIVEL") (BOUND-UNIT-OFFSET 22246) (TASK-DEVICE 6667) (TSA-ADDRESS 75576) (TSA-TRAP-NUM 34) (TSA-INSTR 40772) (TSA-PC 40772) (BOUND-UNIT "ZQLXPT") (BOUND-UNIT-OFFSET 1896) ), where hexadecimal numbers have been translated into decimal notation.

Each symptom in this list is associated with a weight, and the sum of the weights for each symptom constitutes the total weight of the problem. To perform the match, module 107-5 looks for each of the symptoms in the above list in each of the problem descriptions stored in the KPF and adds the corresponding weight to a counter for that description if the symptom is found in its symptom list. When done with all symptoms for the present problem, module 107-5 looks for all the KPF descriptions that have counters with values within 10% of the total weight for the current problem. All such KPF problems are considered to be matches and are displayed.

Since a match was found by module 107-5, test 107-9 results in the reporting of messages 8-17 and 8-18 by module 107-8 for the present example according to the state of the KPF at the time the sample dump was processed. The test 107-10 passes control to module 107-6 which reports a success and generates message 8-19 in FIG. 8, completing the diagnosis of memory dump of the present example.

From the above, it is seen how the system of the present invention automatically diagnoses problems for a number of memory dumps. The organization of the knowledge base in terms of operating system control structure objects and major symptom and subsymptom rules facilitates expansion. The system organization which provides for the creation of the operating system control structures on a demand basis minimizes the amount of data required to be transferred between the host and expert systems.

The system reduces the amount of knowledge required to perform memory dump analysis when human intervention can not be avoided by including the facility for generating full or summary reports as the result of analyzing a memory dump. The known problem file facility of the system avoids having to solve the same problem twice.

It will be apparent to those skilled in the art that many changes may be made to the preferred embodiment of the present invention. For example, while a single host computer system was shown, the present invention may be used to process requests from any number of host systems. Conversely, while the preferred embodiment of the invention utilizes a remote host containing a retrieval module and a local system containing a control module and a knowledge representation module, these control, knowledge representation, and retrieval modules can be resident on a single computer system. The invention is not limited to particular communications links, protocols, data structure formats, etc.

The following provides a short representative listing of certain ones of the control module rules and operating system control structures in the LISP programming language and the Goldhill GoldWorks expert system building tool object-oriented language. ##SPC1##

While in accordance with the provisions and statutes there has been illustrated and described the best form of the invention, certain changes may be made without departing from the spirit of the invention as set forth in the appended claims and that in some cases, certain features of the invention may be used to advantage without a corresponding use of other features.