Error prevention in computer systems

Abstract: Errors are prevented in a computer system by operation of control units (8-12) associated in a one-to-one relationship with functional units (3-7). The functional units perform low-level tasks and are activated via the associated control unit, which performs automatic rollback to check for atomicity of previous events and then detects data events of the associated functional unit. An event log (22) is updated upon successful completion of an event, and if a complete event set has been implemented a flag is set in a fault control log (23). Between operation of functional units, each control unit detects any system faults and re-starts processing according to a commitment boundary retrieved from the fault control log (23).

Description: The invention relates to error prevention in computer systems, and particularly for functional units for performing specific low-level tasks. Examples of such tasks are:- filtering data records; filtering data access requests; deleting data records; appending data records. The invention relates particularly to monitoring of events which are implemented by such functional units so that faults may be detected and suitable recovery made when required. The invention also relates to a manner of generating the functional unit initially so that errors can be prevented. Heretofore, various general fault-detection systems have been developed. For example, British Patent Specification No. GB 2,276,737A describes a method of transaction-orientated data processing in which operation requests or data packets may be marked to be excluded from the effects of application-requested backouts. Such backouts are made following discovery of an error condition prior to successful completion of a transaction which should be atomic. While this method appears to be quite useful, the present invention is directed towards providing for functionality control at a more "fine-grained" level to prevent as much as possible and to handle faults which arise in data processing. The document EP-A-0 319 034 discloses a method of recovering failure of online control program in a multi processor processing system, where each processor execute its own online control program, by means of a take-over process making use of taking-over information stored in a common storage. According to the invention, there is provided an error prevention method carried out in a computer system comprising a plurality of functional units stored in a non-volatile memory device and having code to direct low-level system operations, the system also comprising a control means for error prevention, characterised in that said control means comprises a plurality of control units and an initialisation unit, and the method comprises the steps of a control unit:- storing codes which associate it in a one-to-one relationship with a particular functional unit; receiving an activation instruction for the associated functional unit; automatically verifying hardware initialisation parameters associated with a functional unit activation request received from a user interface by reference to a set of reference hardware circuit parameters stored in a data set; automatically verifying the source of a request for activation of the associated functional unit by reference to a stored data set of access parameters; activating the associated functional unit only after automatically performing a rollback operation having the following sub-steps:- reading entries in a fault control log to determine if all events implemented by the previously operational functional unit have a stored commit flag indicating that an event set has been implemented in an atomic manner; and re-activating the previously-activated functional unit if all commit flags are not detected; updating the fault control log during operation of its associated functional unit by monitoring data event implementation and by :- determining if an event is correctly implemented and directing retries if not, setting a flag in an event log if an event is correctly implemented, determining when all events of an event set are complete, setting a flag in the fault control log when the event set is complete; and activating a next functional unit which is in a verified operational sequential order from the associated functional unit. In one embodiment, each control unit determines when all events of an event set are complete by monitoring the value of a counter in the event log, said counter being incremented upon successful implementation of each event. Preferably, each control unit automatically detects a system fault before a next functional unit is activated. In another embodiment, each control unit automatically retrieves a commitment boundary and re-activates a sequence of previously-operated functional units for system fault rollback according to the commitment boundary. In a still further embodiment, each control unit automatically generates an error signal for an output interface if an event is not correctly implemented and it stores code indicating that an retry is not allowed. In another embodiment, the initialisation unit generates a functional unit by automatic conversion of a generic functional unit including instruction and textual references to a dummy file, conversion being carried out by automatic deletion of such references and insertion of specific file references using text processing steps. Preferably, flag settings for the event log are connected to the input of a logic gate for outputting a fault log setting command when a flag is set for all events of an event set. The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only, with reference to the accompanying drawings, in which :- Fig. 1 is a schematic representation of interconnection of control and functional units in a computer system; Figs. 2(a), 2(b) and 2(c) are flow diagrams illustrating operation of a control unit; and Fig. 3 is a diagrammatic representation of the structure of a functional unit and the manner in which it is generated. Referring to the drawings, and initially to Fig. 1 there is shown part of a computer system. A microprocessor circuit 1 is illustrated and this is of the type connected in an IBM AS/400™ minicomputer. A 32 bit wide address bus 2 is connected to the microprocessor circuit 1. The address bus 2 is connected to a set of five functional units 3 - 7. Construction of the functional units depends on the nature of the functions carried out by the particular unit. These are to carry out low level operations within a computer system such as a minicomputer. The functions are at the operating system level and lie underneath any application software which is loaded in the computer system. The functional units are implemented in software code and accordingly the connections shown are logical rather than physical. The type of functions which can be carried out by the functional units 3 - 7 include :- filtering data access instructions and managing such instructions generally for data access security; deleting records from data files under control of application software; generating display screen commands; updating existing records; and creating records in data files. The invention provides a set of control units 8 - 12, each of which is connected to a functional unit 3 - 7 in a one-to-one relationship by the microprocessor circuit 1 as illustrated by the conductor 13. The purpose of each control unit 8 - 12 is to control operation of the associated one of the functional units 3 - 7 so that access to data may be controlled, faults may be detected and the necessary recovery operations implemented to avoid a chain-effect in which faults propagate. How this is achieved is described below. The control units 8 - 12 are connected to non-volatile memory blocks including a hardware circuit parameter data set 20, a data access parameter data set 21, an event log 22, and a fault control log 23. As described below, the combination of operation of the control units 8 - 12 and of the functional units 3 - 7 with reference to the various data sets and logs provides for early detection of faults and prevention of fault propagation. Referring now to Fig. 2, the manner in which the control units 8 -12 operate is now described in more detail. Although not shown in Fig. 1, there are various user interfaces such as terminals connected to the microprocessor circuit 1 and these interfaces transmit functional unit activation instructions as indicated by the numeral 31. Such an instruction is detected by the associated control unit 8. For clarity, the following description refers to the functional unit 3 and its associated control unit 8. The control unit 8 detects the activation instruction for the functional unit 3 and automatically verifies initialisation of the hardware parts necessary to operate under control of the functional unit 3. The control unit 8 achieves this by automatic reference to the hardware circuit data set 20 in which the model number, speed, and processor type of the interface and any interconnected processors is verified to ensure that there is no incompatibility. Attempts to use an inadequate or incorrect hardware specification when implementing an instruction are not allowed. In step 33, the control unit 8 captures the access code which is being used and this is automatically verified by reference to the data access data set 21. Step 33 is important as it identifies the personal user which establishes the connection and in combination with the verification step 32 provides for comprehensive access control. In step 41 the control unit 8 activates the associated functional unit 3 to perform the particular task, say appending a record to a data file. However, before the control unit 8 allows the functional unit 3 to implement any steps, it performs automatic rollback in step 40 by reference to rollback/commit flags written to the fault control log 23. This automatic rollback operation will be described in more detail below. Provided there are no problems, in step 42 the control unit 8 allows the functional unit 3 to perform the various operations which are involved in its functional operation and it monitors events. The control unit 8 automatically detects data events such as the writing of a byte of data to a non-volatile storage device or to read/write memory. This is achieved by monitoring Write Enable status settings on memory control lines. A step which is carried out by the control unit 8 in tandem with the event monitoring step 42 is an event control step 43 illustrated in detail in Fig. 2(b). In step 43(a) the control unit 8 determines if an event is a data event. A data event is one which may affect data integrity. It does not include the reading of data as this latter event cannot change the data. In step 4(b), the control unit 8 determines if the functional unit 3 has correctly carried out the particular event. This may be the writing of a record to a file, or the writing of an item of data to a record. If it has not been carried out correctly, the control unit 8 includes code which indicates whether or not a retry should be carried out as indicated by the decision step 43(c). If there should be no retry, an error indicator is written to the log 22 in step 43(d). The event is re-started by the step 43(e) if a retry is allowed. When the event has been correctly implemented, the control unit 8 sets a flag in the log 22 to indicate this fact. This is indicated by the step 43(f). In step 43(g), the control unit 8 refers to a counter in the log 22 to determine if the event is the final event in an event set. An event set is defined as a group of events which together perform a particular atomic operation or transaction. For example, the event set for appending a data record includes the events of writing the data record, updating the relevant file header, and also updating the file allocation table of the non-volatile memory device. If it is the final event, a flag indicating that the complete event set has been implemented is written to the log 23 in step 43(h). If it is not the final event, in step 43(i), the counter in the log 22 is incremented. A circuit which is used under the control of the control unit 8 and the functional unit 3 to carry out the latter sub-steps of step 43 is shown in Fig. 2(c). In the event log 22, there are four flags #1, #2, #3 and #4 for an event set. These flags are set by flag setting commands from the control unit 8 as a result of step 43(f). When all four flags have been set, an AND gate 55 may transmit a signal setting the event set flag in the log 23. Further, the signal enables the next event, if requested in a signal from the functional unit 3. In addition to writing a commit flag for the complete event set to the fault log 23, it is envisaged that the control unit 8 may also write such a flag to the event log 22. This would provide a double record of performance of atomic transactions. For clarity, the example given above is extremely simple, however, the individual event may be at a much lower level than the full writing of a record to a file. Each individual event may be the successful writing of a byte of information to a file. Another important aspect of operation of the control unit 8 is that it monitors system faults as indicated by the step 47 in Fig. 2(a). Such faults are quite serious as they may relate to a breakdown in communications between parts of the computer system, disk read errors, or corruption of data. Such monitoring takes place between operation of different functional units in an automatic manner. Provided no such faults are detected, the control unit 8 activates the next functional unit 4,5,6 or 7 depending on the necessary sequence of operations. This is indicated by the step 48 and when the next functional unit is activated, it performs automatic rollback as indicated by the step 40. This automatic rollback step is very important as it involves the control unit which is associated with the next functional unit automatically reading the fault control log 23 to determine if there is a commit flag for all of the event sets performed by the previous functional unit. This rollback operation is performed automatically by the associated control unit whenever a new functional unit is to be activated. This is very important in helping to ensure that faults do not propagate through the computer system. Operation of the control units in conjunction with the functional units in this matter provides a simple method for ensuring that all operations (event sets) are atomic and faults do not propagate. If a system fault is detected as indicated by the step 47, in step 49 the control unit associated with the functional unit which is currently activated automatically determines the commitment boundary. The commitment boundary is also recorded in the fault control log 23 and it provides the boundary of how far back the control unit can trace the previous functional units which have been activated so that processing may be re-started. For example, if the functional units 4,5 and 7 have been activated and the next functional unit is the unit 3, the control unit 8 can trace back the history of operation of each of the previous three functional units and direct re-activation of the functional unit 4, provided this falls within the commitment boundary. In step 50, the relevant control unit activates a sequence of functional units to re-start processing. Accordingly, each control unit is constructed for both monitoring and fault control of its associated functional unit in a very objective manner and also for activation of other units for earlier processing stages. Another aspect of the invention is the manner in which the functional units 3 to 7 are initially generated. This method is indicated by the numeral 70 in Fig. 3 and it is carried out by an initialisation unit within the system with reference to a generic functional unit 60. The generic functional unit 60 includes access codes 61 including an address 62. The unit 60 also has a command set 63 having individual commands 64. In this embodiment, there are k commands 64, commands 1,2,3 and i,j,k being illustrated diagrammatically. Within the commands 64, there may be references 65 to a dummy file. These take the form of two different types. The type of reference 65 included in the command 3 is an instruction command, whereas that included in the command i is for display of text. The generic functional unit 60 is comprehensively tested initially by inputting an extensive range of test instructions and monitoring the outputs which are generated. The method 70 is carried out to convert the generic functional unit 60 to a specific unit which may be used for a particular task. In step 71 the initialisation unit retrieves a first command and searches it in step 72 using conventional text searching techniques. This is possible because there is a set of pre-defined mnemonics which are used for references to dummy files and which could not be confused with other instructions within the commands 64. If a dummy file reference is detected as indicated by the decision step 73, in step 74 the reference is deleted and is replaced by an equivalent reference to a specific file. Steps 71,72,73 and 74 are repeated for each additional command as indicated by the step 75 and when all commands have been processed in this manner, the microprocessor circuit 1 records data indicating that there is now a specific functional unit having a particular function. A control unit is then linked to the functional unit. The method 70 is carried out in a simple manner using text searching techniques and is therefore very efficient. Further, the specific functional unit which is generated has been thoroughly tested and no re-testing is required. This development helps to prevent errors arising during operation of the computer system. It will be appreciated that the invention provides for control of functional units in a simple manner whereby faults may be detected early and propagation of faults avoided. It also provides for effective monitoring of the events carried out by the functional units. The invention is not limited to the embodiments hereinbefore described, but may be varied in construction and detail.

Claims: An error prevention method carried out in a computer system comprising a plurality of functional units (3-7) stored in a non-volatile memory device and having code to direct low-level system operations, the system also comprising a control means for error prevention, characterised in that said control means comprises a plurality of control units (8-12) and an initialisation unit, and the method comprises the steps of a control unit:- storing codes which associate it in a one-to-one relationship with a particular functional unit; receiving (31) an activation instruction for the associated functional unit; automatically verifying (32) hardware initialisation parameters associated with a functional unit activation request received from a user interface by reference to a set (20) of reference hardware circuit parameters stored in a data set; automatically verifying (33) the source of a request for activation of the associated functional unit by reference to a stored data set (21) of access parameters; activating (41) the associated functional unit only after automatically performing a rollback operation (40) having the following sub-steps:- reading entries in a fault control log (23) to determine if all events implemented by the previously operational functional unit have a stored commit flag indicating that an event set has been implemented in an atomic manner; and re-activating the previously-activated functional unit if all commit flags are not detected; updating the fault control log during operation of its associated functional unit by monitoring (42) data event implementation and by :- determining (43(b)) if an event is correctly implemented and directing retries if not, setting (43(f)) a flag in an event log (22) if an event is correctly implemented, determining (43(g)) when all events of an event set are complete, and setting (43(h)) a flag in the fault control log when the event set is complete; and activating (48) a next functional unit which is in a verified operational sequential order from the associated functional unit. A method as claimed in claim 1 wherein each control unit determines when all events of an event set are complete by monitoring the value of a counter in the event log (22), said counter being incremented upon successful implementation of each event. A method as claimed in any preceding claim wherein each control unit automatically detects (47) a system fault before a next functional unit is activated. A method as claimed in claim 3, wherein each control unit automatically retrieves a commitment boundary (49) and re-activates a sequence of previously-operated functional units for system fault rollback according to the commitment boundary. A method as claimed in claim 4, wherein each control unit automatically generates (43(d)) an error signal for an output interface if an event is not correctly implemented and it stores code indicating that a retry is not allowed. A method as claimed in any preceding claim wherein the initialisation unit generates a functional unit by automatic conversion (70) of a generic functional unit (60) including instruction and textual references to a dummy file, conversion being carried out by automatic deletion (74) of such references and insertion of specific file references using text processing steps. A method as claimed in any preceding claim wherein flag settings for the event log are connected to the input of a logic gate (55) for outputting a fault log setting command when a flag is set for all events of an event set.

Inventors: FANNING DARRAGH, FANNING, DARRAGH
Applicants: FANNING DARRAGH, FANNING, DARRAGH
Application year: 1995
Main classification: G06F11
IPC codes: G06F11