Bi-Directional Translator for Diagnostic Sensor Data

The present invention relates to translating between low level data records having both interrelated time dependencies and having a large plurality of varying formats as, for example, the bit oriented output by diagnostic sensors for a mass data storage system, and substantially equivalent high level data having English-like terms where statements of this latter data are not interrelated by time dependencies and such that the data format is substantially fixed and uniform.

As computational systems become increasingly more complex, the data output has become more varied and complex. In particular, for system data output for diagnostic purposes from a mass data storage system, this is especially true. It is not uncommon for such diagnostic data captured as "log data" in "system log" files to be:

(1.1) extremely voluminous: In fact, such logs can be some of the system's largest data storage collections;

(1.2) extremely cryptic: It is not uncommon for the data to be encoded as merely strings of bits. Further, the data can be in a plurality of substantially distinct data formats represented among the bit strings where each format has a unique set of interpretation rules. Note that this can be particularly true of computational systems with cooperating devices where the individual devices were developed substantially in isolation from one another;

(1.3) subject to frequent change: The format and information content of log data records may fluctuate substantially as new information is required for new computational system problems that must be diagnosed.

(1.4) irrelevant data: Large amounts of data may be useless for diagnosis; e.g., because it is irrelevant or outdated and thus no longer applicable.

Furthermore, since the computational system anomalies may be so intermittent or sparsely manifested in the log that they are difficult to detect. Thus, it is not unusual for there to be only a few individuals who possess a sufficient background to understand such log data. Moreover, these individuals are likely to be senior engineers whose time is in high demand as system designers rather than system debuggers. To facilitate the use of such diagnostic data, a data translation and retrieval system is required which substantially alleviates the burden of the above drawbacks, (1.1) through (1.4). By translating between the cryptic ideocycratic formats within such data and a more uniform and comprehensible data representation, a more cost effective diagnosis process can be instituted whereby fewer highly skilled personnel are required in the diagnosis of, for example, computational system faults at a customer site.

The present invention relates to a method and apparatus for translation between low level data records having both interrelated time dependencies and having a large plurality of varying formats, and high level data having English, English-like or, more generally, natural language terms where statements of this latter data are not interrelated by time dependencies and such that the data format is substantially fixed and uniform.

The invention is presently embodied within a larger system for diagnosing anomalies in a computational system where the anomalies relate to the transfer and storage of data between at least one host computer interconnected to at least one robotic archival mass data storage device. However, the architecture for the translation system of the present invention can be easily adapted to translate system logs for anomalous behavior in other computational systems. That is, at a high level, the architecture of the novel translation system is substantially independent of both the computational system and the particular anomalies being diagnosed.

The novel translator of the present invention operates cooperatively with an intelligent analysis module during the diagnosis process. In response to a request for input from the intelligent analysis module, the present invention extracts and subsequently interprets or categorizes data records from a system log data repository thereby creating intermediate semantic structures having a substantially uniform format, the format being substantially independent of any log data record format. Subsequently, these intermediate semantic structures are used in creating high level semantic structures related to the anomaly being diagnosed. In this two stage translation process, a filtering and combining of data is performed whereby data not pertinent to a current information request is filtered out and pertinent data having redundancies is combined, thereby reducing the redundancies. Thus, for example, multiple intermediate semantic structures are coalesced into a single high level semantic structure. Therefore, the present invention effectively transforms low level device and/or process specific log data records related at least by their sequence within a system log into high level natural language based semantic structures. Moreover, in accomplishing this, the present invention advantageously insulates the intelligent analysis module from format changes in the log data records.

Other features and advantages of the present invention will become apparent from the detailed description and accompanying figures contained hereinafter.

FIG. 1 is a block diagram of the translation system 100 of the present invention shown in the context of communicating with an intelligent client database 104, an error log database 168 and a report generation module 106;

FIG. 2 illustrates data in (a) event record format, (b) tuple format, (c) metalanguage format and (d) English;

FIG. 3 is a flowchart presenting the steps performed by the interpreter-converter module 108;

FIG. 4 is a flowchart presenting the steps performed by the converter-transcriber module 116;

FIG. 5 illustrates data formats within an event record;

FIG. 6 is a flowchart presenting the steps performed by the transcriber-interpreter module 112; and

FIG. 7 illustrates the data conversion of an event record to a tuple.

Referring to FIG. 1, a diagram of the data translation system 100 embodying the present invention is disclosed. The data translation system 100 translates data between: (a) an intelligent client database 104 used for diagnosing faults within a data storage system 172; (b) an error log database 168 used for storing low level diagnostic data output by the data storage system 172; and (c) a report generation module 106 used for creating reports of the faults diagnosed by the intelligent client database 104.

The error log database 168 contains information about events that occur in the data storage system 172. These events can be errors in the storage system 172 or simply routine observations about the storage system 172. Each event is represented in the error log database 168 as a grouping of event related data having a substantially standardized descriptor or header. Thus, each grouping together with its descriptor is defined hereinafter as an "event record."

Besides interacting with the error log database 168, the translation system 100 also interacts with the intelligent client database 104. The intelligent client database 104 uses data output by the translation system 100, known as "facts" hereinafter. For example, in the current embodiment the intelligent client database 104 is implemented as an expert system using the PROLOG programming language. Thus, the facts obtained from the translation system 100 for diagnosing the causes of faults within storage system 172 are PROLOG predicates. Conversely, the intelligent client database 104 can supply data for translation as input to the translation system 100. For example, in the current embodiment, the intelligent client database 104 provides queries to the error log database 168 such that the queries, written in PROLOG, are translated by the translation system 100 into lower level C programming language data structures suitable for use by the search module 118 in retrieving event records from the error log database 168 as will be discussed further below. In addition, the expert system rules within the intelligent client database 104 can be translated by the translation system 100 into an English language format. Thus, the rules can be output and viewed by a person unfamiliar with the intelligent client database 104.

Before describing the main components of the translation system 100 more thoroughly, it is useful to define the types of data it receives, produces and/or outputs. The lowest level or most cryptic data are the event records, as shown in FIGS. 2(a) and 5(a)-(c). Each event record contains: (a) header data describing essentially what failed and when it failed, and (b) data describing the failure. In FIGS. 5(a)-(c) further detail of event records is shown. The header data includes an event header having the subfields of FIG. 5(c). Also, an initial event record of a series of event records typically includes a product header for identifying the product to which the event record series applies. In regards to the event data, as shown in FIG. 5(b), it is composed of a non-error data portion and an error data portion. The non-error data portion includes binary encoded accounting data providing data relating the containing event record to other records in the error log database 168. The error data portion includes substantially binary encodings of storage system 172 errors. Thus, an event record is a string of binary data having predetermined subfields determined substantially by position only.

As can be appreciated in viewing FIG. 2(a), event records are difficult to comprehend, especially for someone unfamiliar with the format(s) used. In particular, data within event records can be produced from various software packages or software versions and therefore event records are likely to be encoded in a variety of formats. In addition to the cryptic format(s), the event records can be highly time or sequence interrelated, making an analysis of these records substantially context dependent. Further, in certain circumstances the error log database 168 stores event records having nested data structures wherein one such data structure is nested within another, thus compounding the difficulty of accessing and interpreting the data therein.

The next higher level of data above event records used by this translation system 100 are "tuples." One example of a tuple is shown in FIG. 2(b). At this level, data is represented in a functional or predicate format with symbols being substantially alphanumeric. Thus, assuming FIG. 2(b) is a translation of FIG. 2(a) and that both can be interpreted as the failure of, for example, a library storage module number 1 arm mechanism, certainly a tuple is more easily comprehended. Further note that a single tuple can also represent a grouping of multiple event records and/or tuples in a condensed format. For example, the tuple, er(10, 1,t(90,9,3),e(19,3,565),e(10,5,384), e(11,5,208)) can represent a combination of er(10,1,t(90,9,3,12,01,30),e(19,3, 565)), er(10,1,t(90,9,3,13,20,03),e(10,5,389)) and er(10,1, t(90,9,3,14,01,05),e(11,5,208)) indicating failures of disk drive number 1 at sensors 19, 10 and 11 on September 3rd.

A metalanguage level constitutes the next higher level of data used by the translation system 100, as shown in FIG. 2(c). Data records at the metalanguage level are an English-like translation of the data. Another example of metalanguage is: "EVENT:fail; DEVICE:DD#1; SENSOR:7; MONTH:sep; DAY:1." That is, this data is interpreted to mean that a failure occurred on disk drive #1 at sensor #7 on September 1st.

Finally, the translation system 100 is also able to translate data into an English language format, as shown in FIG. 2(d) which is an English translation of FIG. 2(c). Note, however, that the translation system 100 is not limited to these types of formats. The translation system 100 allows predetermined structures or rules for other natural languages to be easily incorporated.

In FIG. 1, the translation system 100 of the present invention is illustrated as composed of four high level submodules, that is, an interpreter-converter module 108, a transcriber-interpreter module 112, a converter-transcriber module 116 and a search module 118. The interpreter-converter module 108 functions as a controller and command interpreter for the translation system 100 thereby receiving commands from the intelligent client database 104 and invoking the transcriber-interpreter module 112 or converter-transcriber module 116 as needed. Thus, data exchanged between the transcriber-interpreter module 112 and the converter-transcriber module 116 is conveyed through the interpreter-converter module 108 rather than between the two modules directly. The interpreter-converter module 108 also outputs data to the intelligent client database 104 at the completion of the translation process. A PROLOG implementation of the major functions of the interpreter-converter module 108 is provided in Appendix A.

The transcriber-interpreter module 112 transcribes and interprets:

(2.1) tuple(s) into a metalanguage equivalent;

(2.2) metalanguage data into one or more substantially equivalent tuples; and/or

(2.3) metalanguage data into an English equivalent for display via an output device such as a CRT (not shown).

The converter-transcriber module 116 converts between event records and tuples. Thus, the converter-transcriber module 116:

(3.1) transforms tuples generated from metalanguage statements by the transcriber-interpreter module 112 to search strings to be used in queries of the error log database 168;

(3.2) transforms event records retrieved from the error log database 168 into tuples; and

(3.3) if necessary, transcribes a plurality of tuples into a collection of less redundant tuples by: (a) combining tuples judged to have substantially the same pertinent information, and (b) by composing tuples to provide a more compact or higher level tuple representation.

Note, that a PROLOG implementation of the major functions of the converter-transcriber module 116 is provided in Appendix E.

The search module 118 receives error log database 168 search or query requests from the converter-transcriber module 116 and initiates a search of the error log database 168 for the event record(s) satisfying the query. Subsequently, a copy of the event records satisfying the query is output to the converter-transcriber module 116 for processing.

Within the transcriber-interpreter module 112, there is an artificially intelligent software component known in the art as an expert system (not shown). This expert system is provided with a rule base that is hierarchically decomposed into three levels of rules: interpreter rules 120 (the first rules used when processing, for example, a tuple(s) into a metalanguage format), sub-interpreter rules 128, and translation rules 136 at the lowest or most specific level. The interpreter rules 120 determine what type of transformation is to be accomplished for given transcriber-interpreter module 112 input data; e.g., which of the translations (2.1)-(2.3) to perform. Furthermore, if a tuple to metalanguage translation is to be performed, then this module determines what tuple data coordinates and symbols must be interpreted. That is, since the converter-transcriber module 116 is designed to be general purpose, a tuple can contain substantially more information than is required. Therefore, when such a tuple is supplied as the input data to the interpreter rules 120 for translation into metalanguage, the rules are used to parse the tuple and locate the relevant data components for further translation.

Having determined the type of processing to be accomplished, the interpreter rules 120 provide the expert system of the transcriber-interpreter module 112 with direction in invoking one or more appropriate sub-interpreter rules 128. Note that a PROLOG version of representative rules for interpreter rules 120 is provided in Appendix B. The sub-interpreter rules 128 determine how input data is to be translated. Note that a PROLOG version of representative rules for the sub-interpreter rules 128 is provided in Appendix C. To accomplish the translation, the sub-interpreter rules 128, in turn, invoke one or more translator rules 136: (a) for translating each input tuple coordinate and symbol identified for translation into a knowledge element(s); (b) for translating each portion of an input metalanguage statement into a component of a tuple; and/or (c) for translating each portion of an input metalanguage statement into an English phrase. Thus, for example, with regard to (a), immediately above, if a tuple product identifier data component is identified as having a value of say 6, a translation rule 136 can translate this value into the knowledge element "product:acs4430" which is more suitable, in general, for symbolic manipulation in the client database 104 and also more easily understood by an operator or user. Note that a PROLOG version of representative rules for the translation rules 136 is provided in Appendix D.

Within the converter-transcriber module 116, a transcriber module 124 is used to parse the converter-transcriber module 116 input (i.e., tuples or event records). Note that a C programming language implementation of the major functions of the transcriber module 124 is provided in Appendix F. In addition, the transcriber module 124 also invokes one or more sub-transcriber modules 150 to generate appropriate data structures to be output by the converter-transcriber module 116 or (i.e., event record queries or tuples). Note that a C programming language implementation of the major functions of the sub-transcriber modules 150 is provided in Appendix G. Further, the transcriber module 124 also invokes one or more converter modules 152 to convert values between low level primitive data types such as between Binary Coded Decimal format and hexadecimal format. That is, each of the converter modules 152 provide the capability to convert between two such low level data types. Note that a C programming language implementation of the major functions of the converter modules 152 is provided in Appendix H.

Referring now to FIG. 3, a flowchart is presented of the high level steps performed by the interpreter-converter module 108. In step 300, the interpreter-converter module 108 waits for a command to be received from the intelligent client database 104. In step 304, the interpreter-converter module 108 tests whether the received command requires retrieval and conversion of one or more event records into a metalanguage format. If the command requires such a task, the interpreter-converter module 108 invokes the converter-transcriber module 116 in step 308 to retrieve the appropriate event record(s) from the error log database 168 and subsequently to translate the retrieved event record(s) into a tuple(s). As an aside, note that typically in order to perform this step, a metalanguage error log database search query must be translated into a binary search query as discussed in steps 332-340 below. Next, in step 312, the interpreter-converter module 108 invokes the transcriber-interpreter module 112 to translate the tuple(s) output by the converter-translator module 116 into metalanguage format. In step 316, the interpreter-converter module 108 then outputs the metalanguage data corresponding to the tuple(s) to the intelligent client database 104. Subsequently, in step 348, a determination is made as to whether the command currently being processed includes further directives. If not, then control loops back to step 300 in preparation for the next command. Alternatively, if there are further directives, then control loops back to step 304 for processing the additional directives.

If in step 304, the command does not require further retrieval of error log data, the interpreter-converter module 108 performs step 320. In step 320, the interpreter-converter module 108 tests whether the intelligent client database 104 requires a translation of one of its expert system rules. If this is true, in step 324, the interpreter-converter module 108 invokes the transcriber-interpreter module 112 to translate the input rule into an English language format. In step 328, the interpreter-converter module 108 outputs an English translation of the metalanguage corresponding to the rule(s) to the intelligent client database 104. Subsequently, step 348 is encountered and control is directed as appropriate.

If in step 320, the command from the intelligent client database 104 does not require further conversion of metalanguage rules to English language, the interpreter-converter module 108 proceeds to step 332. In step 332, the interpreter-converter module 108 tests whether a metalanguage query or fact pattern is to be converted into a binary query (typically for use in matching against event records when searching the error log database 168). If the command does require such a task, in step 336, the interpreter-converter module 108 invokes the transcriber-interpreter module 112 to translate the metalanguage query into a tuple (or query tuple) having substantially the same semantics and to output the result to the interpreter-converter module 108. In step 340, the interpreter-converter module 108 invokes the converter-transcriber module 116 to convert the output query tuple into a binary template suitable for matching against error log database 168 event records.

Referring now to FIG. 4, a flowchart is presented of the high level steps performed by the converter-transcriber module 116. In step 400, the converter-transcriber module 116 receives a command and tuple data from the interpreter-converter module 108. In step 404, the converter-transcriber module 116 tests whether the command requires that input tuple data is to be converted to binary query data. If so, in step 406, the converter-transcriber module 116 invokes the transcriber module 124 to convert the input tuple data into binary query data. Subsequently, regardless of the path taken from step 404, step 408 is encountered. In step 408, a determination is made as to whether an event record(s) is to be retrieved from the error log database and converted into a tuple(s). If so, then in step 412, the search module 118 is invoked to search the error log database 168. Thus, the search module 118 connects to the error log database 168 and retrieves the event records which match the query. Once the search module 164 has retrieved the query satisfying event record(s), in step 416, the converter-transcriber module 116 again invokes the transcriber module 124 to transform the retrieved event record(s) into a tuple(s). Note that the transcriber module 124 is programmed to recognize each of a plurality of event record types occurring in the error log database 168. Thus, upon parsing the retrieved event record(s), the transcriber module 124 invokes converter modules 152 to transform specific primitive or atomic binary fields of the retrieved event record(s) pertinent to the query tuple.

Once the converter modules 152 convert the atomic binary subfields, the transcriber module 124 invokes one or more sub-interpreter modules 150 to structure the output from the converter modules 152 into a tuple(s) for subsequent output to the interpreter-converter 108. Thus, for example, conversion of the event record in FIG. 7(a) can produce the string of decimal numbers shown in FIG. 7(b). The transcriber module 124 then transcribes the string of numbers into a tuple, as shown in FIG. 7(c).

Further, note that the transcriber module 124 in generating a tuple(s) recognizes commonality and redundancy among both retrieved event records and generated tuples. Thus, in particular, if duplicate tuples are generated, then typically all but one such tuple is deleted from further processing.

Thus, referring to step 420 of FIG. 4, once the transcription is complete, the converter-transcriber module 116 outputs a query satisfying tuple(s) to the interpreter-converter module 108.

Alternatively, if in step 408, the interpreter-converter module 108 does not require the converter-transcriber module 116 to retrieve an event record(s), then the test in step 424 is performed. Step 424 tests whether the interpreter-converter module 108 requires the converter-transcriber module 116 to convert one or more input tuples to a data representation suitable for the report generation module 106. If so, in step 428, the converter-transcriber module 116 invokes the transcriber module 124. The transcriber module 124 invokes both one or more converter modules 152 to convert primitive data types as appropriate, and a predetermined sub-interpreter module 150 that outputs data in a form suitable to the report generation module 106. Thus, in step 432, the converter-transcriber module 116 outputs the report data to the report generation module 106.

Referring now to FIG. 6, a flowchart is presented of the high level steps performed by the transcriber-interpreter module 112. In step 600, the transcriber-interpreter module 112 receives a command and data from the interpreter-converter module 108. In step 604, the transcriber-interpreter module 112 determines the type of translation to perform, that is, one of (2.1)-(2.3) as given above and in step 604. Once the determination is made, in step 608, interpreter rules 120 are used to determine the portion(s) of the input data to be transformed. In step 612, sub-interpreter rules 128 are used to determine how to transform the individual data components of the portions of the input data determined in step 608. If, in step 616, it is determined that there are further individual data components to be transformed, then in step 620 the translation rules 156 are used to translate the data components into the desired format. Subsequently, step 612 is again encountered. Thus, step 612 iteratively activates step 620 until all data components have been transformed. Once all data components have been transformed, step 624 is performed wherein the sub-interpreter rules 128 are used to construct the output in the desired format.

As an example of the process of FIG. 6, if the interpreter-converter module 108 inputs the tuple "er(1, 1, 7, 9, 4, d(3, 1, 9, 0, 3))," with a command to convert this tuple into a metalanguage equivalent, then the interpreter rules 120 parse the data into 1, 1, 7, 9, 4 and d(3, 1, 9, 0, 3). Subsequently, the interpreter rules 120 cause the appropriate sub-interpreter rules 128 to be activated based on the "event type" code contained in the first element location. The sub-interpreter rules 128 cause the appropriate translation rules 136 to be activated for each individual data component. Therefore, for example, the translation of "1","1","7","9","4" to metalanguage format yields "EVENT:fail; DEVICE:DD#1; SENSOR:7; MONTH:sep; DAY:1." Similarly, the translation of the "d(3, 1, 9, 0, 3)" yields "TIME:03:19:03." Given these translations, the sub-interpreter rules 128 combine the metalanguage terms to form the complete metalanguage expression: "EVENT:fail; DEVICE:DD#1; SENSOR:7; MONTH:sep; DAY:1; TIME:03:19:03," which indicates a failure of disk drive #1 occurred on September 1 at 3:19:03 AM at sensor location 7. Once the sub-interpreter rules 128 have been activated to organize the data produced by the translator rules 136, the transformed data is output to the transcriber-interpreter module 112 which, in turn, outputs the metalanguage data to the interpreter-converter module 108.

As a further example of the process of FIG. 6, if the interpreter-converter module 108 inputs the metalanguage statement "EVENT:fail; DEVICE:DD#1; SENSOR:7; MONTH:sep; DAY:1; TIME:03:19:03," with a command to translate this metalanguage statement in an English equivalent, then the interpreter rules 120 are used to parse the statement into the following individual data components: "EVENT:fail," "DEVICE:DD#1," "SENSOR:7," "MONTH:sep," "DAY:1" and "TIME:03:19:03." Subsequently, the interpreter rules 120 cause the activation of the appropriate sub-interpreter rules 128 for outputting an English translation. The sub-interpreter rules 128 cause the activation of the translation rules 136 for translating each of the above data components into English phrases. The following English phrases are obtained: "a failure occurred," "on disk drive #1," "at sensor #7," "in September," "1st" and "at 3:19:03 AM." Subsequently, the sub-interpreter rules 128 combine and rearrange as necessary these English phrases. For example, the above English phrases yield: "A failure occurred on disk drive #1 at sensor #7 on Sep. 1st at 3:19:03 AM." Finally, this result is output to the interpreter-converter module 108.

The following example further illustrates the operation of the translation system 100. The example relates to diagnosing errors occurring in a data storage system 172 such as a disk drive data storage system. More precisely, the disk drive data storage system consists of multiple disk drives and multiple sensors that output event records corresponding to failures of the components of the system. The attributes of each such event record are: the type of failure, the device affected, the name of the product family of the device, the time of the event, the version number of the software used to report the error, the sequence number of this event record in the error log database and the sensor data corresponding to the error. Therefore, assume the following data for event records is in the error log database 168:

If translated by the translation system 100, there is an event record, E, within this data which translates to: "On Dec. 21, 1990 at 8:09 am in Library Storage Module 1, the Z mechanism motor stopped working. This caused the Z mechanism and the Library Storage Module 1 to become inoperative."

While the above error log data overwhelms and confuses an untrained person, the translation system 100 of the present invention can convert the data to a common format and subsequently translate the data for use by a system that can diagnose the cause of the system malfunction.

The translation of the error log data commences with the intelligent client database 104 sending a command and a metalanguage query to the translation system 100 requesting a metalanguage version of, for instance, the event record E. The interpreter-converter module 108 of the translation system 100 receives the command and interprets the command to mean that an event record is to be retrieved from error log database 168. The interpreter-converter module 108 subsequently invokes the transcriber-interpreter module 112 to transform the metalanguage query into a query tuple. Following this, the interpreter-converter module 108 invokes the converter-transcriber module 116 with the query tuple and any data describing the search location.

The converter-transcriber module 116 transforms the query tuple into a binary query to search the error log database 168 and retrieve the event record E. In accomplishing this, the converter-transcriber module 116 invokes the search module 118 to retrieve the event record E from the error log database 168. In this example, the event record E is: "0A01002A90122108 0922110000003035 3937310014DB000D 01A5020A000CD006 000400000000FFFF FFFF0350003A9004 00200007FCE0038." The search module 118 subsequently returns this event record to the converter-transcriber module 116 which, in turn, invokes the transcriber module 124 and conveys event record E.

The transcriber module 124 parses the event record E. For example, the event record E is first parsed into two areas: the header and the product specific data. The header data of this event record is 0A01002A90122108 092211000000. The product specific data is 3035 3937310014DB000D 01A5020A000CD006 000400000000FFFF FFFF0350003A9004 000200007FCE0038. Programmed with the composition and organization of the event record data, the transcriber module 124 can further parse the data into subsets to be converted by the conversion modules 152. For example, regarding the header data the transcriber module 124 invokes a converter module 152 to convert 0A, the first subset of data in the header data, from its hexadecimal value to 10, its decimal value. Similarly, 01 is converted to 1 and 002A is converted to 42. Since the remainder of the header data 90122108 09221100 is presently encoded in Binary Coded Decimal (BCD), the transcriber module 124 invokes a series of converter modules 152. Therefore, this remaining portion of the header is first converted to hexadecimal by a first converter module 152. This yields 5A0C150809160B00. This hexadecimal string is then converted to decimal by invoking a second converter module 152.

The transcriber module 124 also filters out any unnecessary data not needed for transcription. For example, the following product specific data 3035 3937310014DB00D 01A5020A000C is accounting data. Thus, most of this data is not needed during diagnosis. Therefore, most of this data is not processed. However, the 3035 39373100 portion of the accounting data is processed. This portion represents the Host Identifier number, that is, identification number of the disk data storage system. Programmed with the knowledge that the Host Identifier number is encoded in ASCII, the transcriber module 124 invokes an ASCII to Decimal converter module 152. The Host Identifier number is therefore converted from 3035 39373100 to 05971, i.e., the 30 is converted to a 0 and the 35 is converted to a 5, etc.

After also converting the product specific data of the event record E from its plurality of formats to a series of decimal numbers, the transcriber module 124 subsequently uses the output from each of the converter modules 152 to construct a tuple. Thus, the tuple for the event record E is: er (10, 1, 2, t(90, 12, 21, 08, 09, 22, 11), 0, 6, 2.3, d(98, 5971, s(208, 6, 4, 0, 0, 65535, 65535), e(3, 5, 58), s(144, 4, 2, 0, 32718))) . Note that the t(. . .) , d(. . .) , s(. . .) and e(. . ) terms in the tuple for E are also tuples. Further, note that the designations "er", "t", "d", "s" and "e" uniquely identify each (sub)tuple type.

In addition, if the command from the interpreter-converter module 108 requires it, the converter-transcriber module 116 can invoke the search module 164 to retrieve a second event record from the error log database 168 for conversion to a second tuple. If multiple event records are retrieved and transformed into tuples, the transcriber module 124 can combine the tuples to eliminate substantial redundancy, thereby reducing the number of tuples output. For example, if the following logical tuples are generated by transforming event records:

er(10, 1, 42, t(90, 12, 21, 8, 9, 21, 96), 0, 6, 2.3, d(96, 5971, s(208, 6, 11, 0, 1, 1, 10), s(208, 6, 1, 0, 0, 1, 16596)));

er(10, 1, 42, t(0, 12, 21, 8, 9, 22, 4), 0, 6, 2.3, d(97, 5971, s(208, 6, 2, 0, 0, 0, 13203), s(208, 6, 3, 0, 0, 65535, 55019))); and

er(10, 1, 46, t(90, 12, 21, 8, 9, 22, 19), 0, 6, 2.3, d(99, 5971, s(176, 6, 2, 0, 0, 0, 13203), e(19, 3,565), s(176, 6, 11, 0, 1, 1, 10))).

Combining the "er" tuples to form one comprehensive tuple that eliminates redundancies, yields:

er(10, 1, 42, t(90, 12, 21, 08, 09, 21, 96), 0, 6, 2.3, d(96, 5971, s(208, 6, 11, 0, 1, 1, 10), s(208, 6, 1, 0, 0, 1, 16596), s(208, 6, 2, 0, 0, 0, 13203), s(208, 6, 3, 0, 0, 65535, 55019), s(208, 6, 4, 0, 0, 65535, 65535), e(3, 5, 58), s(144, 4, 2, 0, 32718, 56), s(176, 6, 2, 0, 0, 0, 13203), e(19, 3, 565), s(176, 6, 11, 0, 1, 1, 10))).

To fulfill the request of the intelligent client database 104 for event record E in metalanguage format, once the converter-transcriber module 116 outputs the tuple corresponding to event record E, the interpreter-converter module 108 invokes the transcriber-interpreter module 112 to translate the tuple corresponding to E into its metalanguage equivalent. Thus, the transcriber-interpreter module 112 first uses the interpreter rules 120 with the event record E tuple, hereinafter, E-tuple. The interpreter rules 120 parse the elements of the E-tuple. Subsequently, the sub-interpreter rules 128 operate on the parsed elements. However, not every element needs to be interpreted. Thus, some parsed elements are discarded. For example, the E-tuple generated is parsed into six elements: 10 in the first coordinate position; 1 in the second coordinate position, t(. . .) in the fourth coordinate position; 6 in the sixth coordinate position; 2.3 in the seventh coordinate position; and d(. . . ) in the eighth coordinate position. Note that the 42 and 0 elements are not used in this interpretation; i.e., they are ignored. Based on position, the elements are interpreted as follows:

10 is the Event Identifier;

1 is the Device Identifier;

t(90, 12, 21, 08, 09, 21, 96) is the Time Stamp;

6 is the Product Identifier;

2.3 is the Software Revision;

d(96, 5971, s(208, 6, 11, 0, 1, 1, 10), s(208, 6, 1, 0, 0, 1, 16596), s(208, 6, 2, 0, 0, 0, 13203), s(208, 6, 3, 0, 0, 65535, 55019), s(208, 6, 4, 0, 0, 65535, 65535), e(3, 5, 58), s(144, 4, 2, 0, 32718, 56), s(176, 6, 2, 0, 0, 0, 13203), e(19, 3,565), s(176, 6, 11, 0, 1, 1, 10)) is the Servo Response.

Subsequently, the sub-interpreter rules 128 cause activation of the translation rules 136 to transform the above data elements into metalanguage format. That is, by activating the sub-interpreter rules 128 that interpret "er" tuples, an interpretation is made of the six elements. That is, the "er" sub-interpreter 128 determines one or more translation rules 136 to be activated for each of the above listed six parsed elements to interpret the E-tuple. Thus, the Event Identifier value, 10, is provided to a translation rule 136 for outputting an attribute identifier, i.e., "event" in this case, followed by a value of the attribute, which corresponds to the value 10; i.e., "device.sub.-- operation" in this case. Thus, the resulting output is the metalanguage term, "event:device.sub.-- operation." Similarly, the "er" sub-interpreter rules 128 activates a "device.sub.-- identifier" translation rule 136 for the second of the above six elements; i.e., the "1" which identifies the device to which the E-tuple applies. Thus, the metalanguage term, "device:1sm.sub.-- 1" is returned indicating that library storage module 1 was affected. Continuing, a time stamp translation rule 136 is activated for the fourth location t(90, 12, 21, 08, 09, 21, 96) and returns the metalanguage term, "year:90, month:12,day:21,hour:8, minute:9,second:21" representing the time when the event record E was generated. In regards to the fourth of the six elements; i.e., the "6", a translation rule 136 transforms this value to "product:acs4430." In regards to the fifth element, i.e., the "2.3," a translation rule 136 transforms this value to "revision:2.3." In regards to the sixth element; i.e., the Servo Response element, d(96, 5971, s(208, 6, 11, 0, 1, 1, 10), s(208, 6, 1, 0, 0, 1, 16596), s(208, 6, 2, 0, 0, 0, 13203), s(208, 6, 3, 0, 0, 65535, 55019), s(208, 6, 4, 0, 0, 65535, 65535), e(3, 5, 58), s(144, 4, 2, 0, 32718, 56), s(176, 6, 2, 0, 0, 0, 13203), e(19, 3, 565), s(176, 6, 11, 0, 1, 1, 10)), one or more translation rules 136 transform this subtuple into the two metalanguage terms, "servo.sub.-- response:[mechanism: z,level:5,error: motor.sub.-- failed]" and "serv.sub.-- response[mechanism:arm, level:3error:move.sub.-- failed]." Further, note that the value 96 in the first coordinate of the d(. . .) subtuple is transformed into the term "sequence:96" and the value 5971 of the second coordinate is transformed into the term "host:5971." Finally, note that the s(. . .) sub-subtuples are not used, therefore, they are ignored.

Thus, the E-tuple is transformed to the metalanguage statement "[event:device.sub.-- operation, device:lsm.sub.-- 1, year:90, month:12, day:21, hour:8, minute:9, second:22, product:acs4430, sequence:98, host:5971, servo.sub.-- response:[mechanism:z,level:5, error:motor.sub.-- failed], servo.sub.-- response:[mechanism:arm, level:3, error:move.sub.-- failed]]" which is output to the intelligent client database 104.

As an example illustrating the use of the translation system 100 in translating from metalanguage input into one or more event records, if the interpreter-converter module 108 receives the metalanguage data "EVENT:fail; DEVICE:DD#1; SENSOR:7; MONTH:sep; DAY:1; TIME:03:19:03" with a command to convert this metalanguage statement to event record(s), then the interpreter-converter module 108 first invokes the transcriber-interpreter 112 with this metalanguage statement. Subsequently, the transcriber-interpreter 112 uses the interpreter rules 120 to parse the metalanguage statement into "EVENT:fail," "DEVICE:DD#1," "SENSOR:7," "MONTH:sep," "DAY:1," and "TIME:03:19:03." Subsequently, the interpreter rules 120 cause the appropriate sub-interpreter rules 128 to be activated. The activated sub-interpreter rules 128 cause the appropriate translation rules 136 to be activated for each individual data component. Thus, the following translations are obtained from the translation rules 136: er(1, .sub.--, .sub.--, .sub.--) from "DEVICE:DD#1"; er(.sub.--, 7, .sub.--, .sub.--)from "SENSOR:7"; er(.sub.--, .sub.--, 9, .sub.--) from "MONTH:sep"; er(.sub.--, .sub.--, .sub.--, 1) from "DAY:1"; d(3, 1, 9, 0, 3) from "TIME:03:19:03." The sub-interpreter rules 128 then are activated to combine the output of the translation rules 136 to produce the tuple: "er(1, 7, 9, 4, d(3, 1, 9, 3))" which is subsequently output to the interpreter-converter module 108.

The interpreter-converter module 108, in turn, supplies this newly generated tuple(s) to the converter-transcriber module 116 for converting to one or more event records. Thus, the transcriber module 124 is invoked to first determine the type of tuple input, in the current example an "er" tuple, and second, to invoke the appropriate sub-interpreter module 150 for parsing of the input tuple into the following tuple terms: "dv(1)" for device 1, "sn(7)" for sensor 7, "dt(9,1,.sub.--)" for the date (i.e., Sep. 1st), "tm (3,19,3)" for the time of day. Various converter modules 152 are invoked to translate each of the above tuple terms. Thus, upon translating each of the above tuple terms, the following event record terms are respectively obtained: 01, 07, 090100 and 031903 where the 090100 and 031903 terms are BCD (Binary Coded Decimal) formatted date and time terms, respectively. Subsequently, a sub-transcriber module 150 combines these event record terms into the event record: 01070901FF031903.

At this point, it is worth mentioning that typically an input metalanguage statement for translation into one or more event records will be a query for the error log database 168. Thus, the metalanguage query statement will have at least one variable or place holder where a value could be and this query statement will translate into one or more event record queries. Thus, if all failure events on device DD#1 on September 1 are desired the initial metalanguage statement input to the interpreter-converter module 108 would be: DEVICE:DD#1, MONTH:SEP, DAY:1, EVENT:[device.sub.-- operation, user.sub.-- request, device.sub.-- failure]. Subsequently, once this metalanguage query is translated, at least the following three lists of event record queries are obtained:

(4.1) a list of event queries corresponding to device DD#1 operation errors:

That is, this list queries for all SERVO.sub.-- RESPONSE errors for which the error log database 168 is to be checked. In particular, the first three are: a motor failure in the motor that moves the robot arm in the vertical (i.e., "z") direction, a tape cartridge fetch failure by robot hand 0, and a failure in flexing finger 0 of a robot hand.

(4.2) a list of event queries corresponding to device DD#1 user request errors:

That is, this list queries for all command responses for which a failure occurred;

(4.3) a list of event queries corresponding to device DD#1 device failures:

That is, this list queries for all servo.sub.-- response failures, the first one being that the left bulb of lamp 0 is not lighting.

The event record queries are subsequently used by the search module 118 in a matching process whereby an event record is retrieved from the error log database 168 whenever it matches all the defined values within an event record query.

The foregoing discussion of the invention has been presented for purposes of illustration and description. Furthermore, the description is not intended to limit the invention to the form disclosed herein. Consequently, variation and modification commensurate with the above teachings, within the skill and knowledge of the relevant art are within the scope of the present invention. The embodiment described hereinabove is further intended to explain the best mode presently known of practicing the invention and to enable others skilled in the art to utilize the invention as such, or in other embodiments, and with various modification required by their particular application or uses of the invention. It is intended that the appended claims be construed to include alternative embodiments to the extent permitted by the prior art. ##SPC1##