JPH03150643A - Fault monitoring device and control method for information processing system - Google Patents

Abstract

PURPOSE:To monitor and recover the fault of a computer system from a remote place by providing a computer system as the controlled object with a monitor controller. CONSTITUTION:An information processing system 250 as the monitored object relays the data line, through which message data is sent to a conventional master console 102, and monitors message data. With respect to detection of hardware fault, a private interface line is provided between a central processing unit 200 and the system to detect the occurrence of fault or gather fault information. Consequently, it is unnecessary to change a conventional operating system, and the malfunction is prevented. Thus, fault monitor and recovery of the information processing system, namely, the computer system are performed from a remote place.

Description

[Detailed Description of the Invention] [Industrial Application Field] The present invention relates to a fault monitoring device for an information processing system and a control method thereof, and in particular, to perform initial diagnosis of the information processing system when a fault occurs from a remote location. Sometimes related to preferred control strategies.

[Conventional technology]

BACKGROUND OF THE INVENTION As the range of applications of information processing systems, that is, electronic computer systems, expands, system configurations are also becoming larger and more complex. Along with this, improvements in the reliability and fault tolerance of information processing systems, as well as early recovery after a fault occurs, are becoming more important.

In recent information processing systems, a control device for maintenance control is added to the information processing system itself.

A configuration that handles maintenance and diagnosis of information processing systems is becoming common. This type of control device is a Service Processor (SV).
P) and U.S. Patent No. 4,204,24
It is disclosed in Publication No. 9. Also, JP-A-58-561
No. 58 discloses a control method for maintaining and diagnosing a plurality of user computer systems from a computer system at a remote maintenance center. Furthermore, JP-A-61-14854
Publication No. 2 discloses a control method that allows the SvP screen to be operated from a remote location.

The technology disclosed in U.S. Patent No. 4,204,249 uses SvP to control power on/off and control microprogram loading for multiple processing device groups.
This enables centralized management. In particular, by directly wiring a dedicated signal line from the control device to each processing device group, there is no need for rewiring compared to the conventional parallel wiring method.

The technique disclosed in Japanese Patent Application Laid-Open No. 58-56158 is such that a computer system at a maintenance center constantly diagnoses a plurality of user computer systems in sequence to detect the occurrence of a failure in advance. In addition, in Japanese Patent Application Laid-open No. 61-148542, when making it possible to operate the SVP screen even from a remote location, the structure and processing procedure of the screen control program on the SVP side and the screen control program on the remote maintenance side are disclosed. In order to achieve the same result, a method is disclosed in which a data buffer is provided on the SvP side and the contents of this data buffer are transferred.

[Problem to be solved by the invention]

By the way, with the expansion of 24-hour operation services and the range of applications for information processing systems, various technological developments have been developed to improve the reliability and fault tolerance of information processing systems, as well as the development of controls for early recovery after a fault occurs. The means are also important. For early recovery, it would be sufficient if system maintenance personnel were permanently stationed at the site of the user computer system, but with the spread of 24-hour operation services, unmanned operation is becoming commonplace, and system maintenance personnel are becoming more and more popular. It is necessary to be able to stand by at a maintenance center and perform fault monitoring and maintenance of multiple user computer systems. What were the challenges at that time?

The objective is to enhance the ability to detect the occurrence of a failure in a user computer system from a remote location, and to provide a control means for early recovery.

From this perspective, regarding the prior art, U.S. Pat.
The technology described in 204,249 facilitates arbitrary changes in power supply devices and wiring as computer system configurations become more complex.
Power on/off with SvP.

and voltage adjustment. However, it does not disclose failure monitoring or maintenance methods from remote locations. In addition, for the processing equipment group of the information processing system, local S
There is a restriction that it must be operated in vP.

The technology described in Japanese Unexamined Patent Publication No. 58-56158 is a technology that allows the maintenance center computer system to be transferred from the local user computer system (
This system communicates with the SvP of the processing device to be diagnosed (processing device to be diagnosed) and patrols and monitors the status of the user computer system.

Therefore, by patrolling and monitoring the status of user computer systems, the aim is to improve the operating status of the computer system at the maintenance center, and to automate diagnosis by cataloging the monitoring procedures. However, failure detection means, specific items of logging information, failure determination criteria, etc. are not specifically disclosed.

On the other hand, the technology described in JP-A-61-148542 is
In order to display the same screen as the 872 screen of the local computer system on a remote display device, a data buffer is provided in the SvP of the local computer system.

The logical structure of the processing program is simplified by displaying the contents of this data buffer on the 872 screen of the local computer system or on a remote display device. This allows the SvP of the local computer system to be operated even from a display device at a remote maintenance center. By the way, svp supports maintenance operations and can detect hardware failures, but software, that is, operating system
5ysteCoS) is generally difficult to detect.

1. Normally, when the O8 is in operation, monitoring of console messages, etc. for the O8 is the main fault detection means. From this point of view, the above-mentioned Japanese Patent Application Laid-Open No. 61-148542
The technology described in the publication does not include the trigger for switching between the remote and local 872 screens, the means for detecting console messages, the method of reporting when a failure occurs, the items to collect failure information from the 872 screen, and the collection method. Not mentioned.

In order to detect failures in user computer systems and achieve early recovery after a failure occurs at a remote maintenance center, the challenge is to create a mechanism that can instantly collect the progress of O8 behavior from a remote location. Remaining 6 Normally, the progress of O8 behavior can be traced by tracing messages output on the OS console, but the hard copy device that outputs console messages is located near the local user computer system. In many cases, the power of the hard copy device is turned off because the hard copy device is running unattended or is operating unattended even if it is nearby. It's for a reason.

Furthermore, when a failure occurs, it is necessary to be able to refer to a specific area within the main storage device from a remote location.

These targets include the area where O8 management information is stored and the area used by the hardware.

Naturally, when operating unmanned vehicles,
There are no operating operators or maintenance personnel on the user computer system side. Therefore, it is desired to provide a control means for detecting the occurrence of a failure. Also, if you recognize that a problem has occurred in a remote location.

An initial analysis of the cause of the failure must be performed before maintenance personnel arrive at the site. Providing these control means contributes to early recovery of a computer system after a failure occurs.

Therefore, one object of the present invention is to provide a control device and control means that enable fault monitoring and recovery of an information processing system, that is, a computer system, from a remote location.

Another object of the present invention is to provide information on the failure of the information processing system from the remote location, specifically, the status of the system at the time of occurrence of the failure, when a notification of the occurrence of a failure in the information processing system is received at a remote location. An object of the present invention is to provide a control device and a control means that can collect operation history information in the process leading to a failure.

Another object of the present invention is to provide a control means that can analyze collected failure information and instruct maintenance personnel to take appropriate recovery procedures when they arrive at the site.

[Means to solve the problem]

In order to achieve the above object, in the fault monitoring device and control method for an information processing system of the present invention, the fault monitoring device is installed between a mask/console device of an information processing system (also referred to as a computer system) to be monitored and controlled. It intervenes and monitors the data stream on the signal line for transmitting and receiving data to and from the information processing system. Furthermore, a dedicated connection interface line is installed between the central processing unit and a mechanism that can receive hardware failure reports from the central processing unit and import specific hardware information within the central processing unit. Equipped with Note that the effect is the same even if a keyboard and display device are added to the control device of the present invention instead of the conventional mask console. In one embodiment of the present invention, the present invention The explanation will be based on a configuration in which a keyboard and a display device are added to the control device.

Furthermore, a second information processing system exists in a remote location that monitors and controls the above information processing system group.

When this second information processing system receives a notification of a failure from the previous control device, it searches for and collates past case law information based on the failure information, automatically generates a recovery procedure for the failure, and then , share the role of forwarding recovery procedures to the site of the information processing system that has experienced the failure.

A supervisory control device that realizes a fault monitoring device for an information processing system and a control method thereof according to the present invention receives message data sent from an information processing system to be monitored and controlled, stores it in a data buffer, and displays it on one display device. Display 8
At this time, at the same time.

Compare with pre-registered failure messages to recognize the occurrence of a failure. In the event of a hardware failure in an information processing system (hereinafter also referred to as a computer system), the failure will be notified via a dedicated interface line. Hardware failures include machine checks,
6. Monitoring and control equipment such as memory error processing unit failure.

In either the former case of a software failure or a hardware failure, information of a specific processing unit within the central processing unit is read out via a dedicated interface line and temporarily stored in a storage area.

When the above-mentioned fault condition is detected, the supervisory control device of the present invention reports the occurrence of the fault to the second information processing system at a remote location. At this time, a plurality of message data stored in the data buffer, that is, a plurality of past message data from the time when the failure occurred, and hardware failure information at the time when the failure occurred are transferred. As a result, the second information processing system for monitoring and maintenance at a remote location (hereinafter referred to as the computer system for monitoring and maintenance) recognizes the occurrence of a failure in the computer system to be monitored and controlled.

When the monitoring/maintenance computer system receives the above report and failure information, it compares the failure information with pre-stored precedent information and generates an optimal recovery procedure. The results are transferred to the supervisory control device of the computer system where the failure has occurred.6 Therefore, when maintenance personnel arrive at the site of the computer system where the failure has occurred, they can issue a command for "recovery instructions" from the console device. By inputting the information, a series of recovery procedures are output to the display screen of the console device or the hard copy device.

As a result, the time from the occurrence of a failure in the computer system to recovery can be shortened, and the operational service of the computer system can be improved.

[Operation] The fault monitoring device and control method for an information processing system according to the present invention is such that the information processing system to be monitored is a conventional master,
It relays the data line that sends message data to the console, and monitors the message data. In addition, regarding the detection method of hardware failure, a dedicated interface line is provided with the central processing unit.
It detects the occurrence of failures and collects failure information.

Therefore, there is no need to modify the conventional operating system, and there is no possibility of it malfunctioning.

〔Example〕

An embodiment of the present invention will be described below with reference to FIGS. 1 to 22. FIG. 1 is a schematic diagram of the configuration of a fault monitoring device and a control method for an information processing system according to the present invention. Reference numeral 200 in the figure is a computer system to be monitored, under which an operating system (Operating System) is installed.
g System :OS ) 208a.

User Program: U
P) 208b is operating. A typical hardware processing unit that constitutes the computer system 2oO is an instruction control unit (Instruction Unit).
IU) 201, execution unit (Execution
Unit: EU) 202, input/output processing unit (1/Q ProcessinlHtlnit: I
OP) 203.

Memory control unit
Unit: MCυ) 204, main memory device (Main S
storage: MS) 206.

and service processor (S6ryiC6Proc
essor:5VP)207. Further, input/output devices such as a file device 209 are connected to the computer system 200.

Reference numeral 100 denotes a supervisory control device which is one of the components of the present invention, and a signal line Ll a for the system console is connected from the computer system 200 to the supervisory control bag e100 of the present invention.
, 5VP207 are connected to the display signal line Llb. In addition, the signal line Lla and 5V for the system console
The display signal line Llb of P207 may be the same signal line. In this case, the signal line Lla is the same as the display signal line Llb of P207.
It is output from O3 via 5VP207.

Further, between the supervisory control device 100 of the present invention and the computer system 200, a request signal L2. They are connected by a signal line L3 including an address bus and a data bus. Here, the address bus and the data bus are shown identically by the signal line L3, but this is for representational purposes only, and as a matter of course, they are connected by different signal lines.

The supervisory control device 100 is composed of an arithmetic unit having processing power similar to that of a microprocessor, a main memory, and a group of processing programs. In the supervisory control bag [100, reference numeral 1 is an encoder, 2 is an address register AD, and 3 is a data register DT. Code 4 is a CPU interface processing unit (CPU Interface), code 5
is the comparison processing unit CMP.

Reference numeral 6 is a data buffer, reference numeral 7 is a comparison table, reference numeral 8 is a diagnostic processing section, and reference numeral 9 is a screen buffer.

Reference numeral 10 represents a failure determination processing unit, and reference numeral 11 represents a distributor.

Reference numeral 12 is a transfer processing section, reference numeral 13 is a command interpretation processing section, and reference numeral 14 is a transmission/reception processing section. In addition.

The monitoring control device 100 includes a display device 10 with a keyboard.
2. - Time storage file 104 is connected.

The monitoring control device 100 and the remote monitoring/maintenance computer system 250 are connected by a line L4.

Note that a public line network may be interposed between the supervisory control device 1oO and the remote monitoring/maintenance computer system 250. Connected to the monitoring/maintenance computer system 250 are a console device 252 for controlling the computer system 250, a file device 254 for storing precedent information, and a failure information storage file 256. Although not shown in FIG. 1, it is of course possible to connect input/output devices that can be connected to the computer system, such as line printers.

In the monitoring/maintenance computer system 250, a group of failure factor analysis programs are running, including a communication processing section 21, an interpretation/command processing section 22, a collection/analysis processing section 23, and a failure factor analysis program group 250. Reference numeral 25 is a collation processing unit, reference numeral 26 is a precedent search/registration processing unit, and reference numeral 24 is a work buffer (Work Buffer: B U F
).

The monitoring/maintenance computer system 250 can manage a plurality of computer systems to be monitored and controlled. Code 100a, 10
0b is another supervisory control device similar to 100, 20
0a and 200b are computer systems to be monitored.

Now, after explaining the outline of the operation of the fault monitoring device and control method for an information processing system of the present invention using FIG.
The details of each processing section will be explained using the explanatory diagrams that follow.

Referring to FIG. 1, messages and data of the OS 208a are sequentially sent from the computer system 200 to be monitored and controlled via the line Lla.

These message data are sequentially stored in the data buffer 6. When the data buffer 6 becomes full, data is stored again from the beginning. Before the message data is stored in the data buffer 6, the comparison processing unit CM
At P5, it is checked whether the message data is equal to message data for failure determination registered in advance in the comparison table 7. As a result of the comparison test, if they match, control is transferred to the failure determination processing section 10.

If the fault is a software fault, the fault determination processing section 10 activates the diagnosis processing section 8 and collects status information of each processing unit in the central processing unit 200 in order to obtain additional hardware information. When collecting status information, the address value of the processing unit is set in the address register AD2, the collection item number is set in the data register DT3, and the information is sent to each processing unit in the central processing unit 200. Each processing unit sends information corresponding to the collection item number to the data bus L3.
Return to. The collected status information is -d.

It is stored in the time storage file 104. Here, the hardware status information is the contents stored in the hardware usage area 206b in the main storage device 206.

State holding information 1 in each processing unit includes, for example, an interrupt holding register and a program status word.

On the other hand, in the case of a hardware failure, it is generally detected by the service processor 5VP 207 and reported to the encoder 1 via line L2. Also.

Faults that cannot be detected by the service processor 5VP 207, such as parity errors in latch circuits, are reported directly from each processing unit to the encoder 1 via line L2. Upon receiving a report of a hardware failure, the CPU interface processing unit 4 activates the diagnostic processing unit 8 to collect status information of each processing unit in the central processing unit 200, and then passes control to the failure determination processing unit 10. Note that in the case of a hardware failure, the history of message data issued by the OS is already stored in the data buffer 6, so no special processing is performed.

When the above processing is completed, the fault determination processing unit 1° notifies the monitoring/maintenance computer system 250 of the occurrence of a fault via the transmission/reception processing unit 14 and the parentheses L4. Note that this reporting process may be performed before collecting the failure information described above.

When the monitoring/maintenance computer system 250 receives a report of a failure, it first investigates the outline of the failure.

Detailed fault information is requested from the supervisory control device 100. This is done via the line L4 (command: Comm
and) data string is sent to the supervisory control device 100.

This command is issued by the interpretation/command processing unit 22.

In the supervisory control device 100, the command interpretation processing section 13 interprets this command and starts the transfer processing section 12. The transfer processing unit 12 will transfer the contents of the data buffer 6 and the failure information stored in the -time storage file 104. At this time, the transfer processing unit 12 transfers only the requested information.
For the data of 06b, editing processing is performed to reduce the amount of data to be transferred.An example of the 0 editing processing is to replace the same data with a mark to that effect if it continues.

The interpretation/command processing unit 22 automatically issues the above command, that is, the fault information transfer command, when receiving a notification of the occurrence of a fault from the supervisory control device 100, but the console device 2
It is also possible to input the corresponding command manually from 52. In that case, the input command is interpreted by the interpretation/command processing unit 22 and passed to the command interpretation processing unit 13 in the supervisory control device 100 via the communication processing unit 21. On the monitoring/maintenance computer system 250 side, the transferred detailed fault information is stored in the fault information storage file 256 via the BUF 24. These series of processes are performed by the collection/analysis processing unit 23.

The collection/analysis processing unit 23 then activates the one-case precedent search/registration processing unit 26 to search the precedent storage file 254 for past failure cases similar to the failure. Thereafter, the collation processing unit 25 collates a precedent that matches the disorder from among the previously searched candidate group.

As a result of the verification, if there is a precedent that matches the disability, 1.
The recovery instruction generation processing unit 27 obtains the recovery procedure stored in the case precedent that matches one match. The recovery procedure is transferred to the supervisory control device 100 via the communication processing unit 21 and stored in the -time storage file 104.

A maintenance person arrives at the site of the computer system 200 where the failure has occurred and issues a ``recovery instruction'' from the console device 102.
When a command to that effect is input, one recovery procedure is output to the display screen of the console device 102 or to the hard copy group W (not shown).

As a result, the cause of the failure is analyzed and the recovery procedure is generated in parallel between the occurrence of the failure and the arrival of the maintenance personnel at the site, thereby reducing the recovery time.

As a result of the comparison, if there is no precedent that matches the failure, the information to that effect is transferred to the supervisory control device 100, so when the maintenance personnel inputs the command ``recovery instruction'', the self-blade is activated. It turns out that it is necessary to perform an analysis for recovery. In that case, the contents of data buffer 6 and temporary storage file 104 may be output to console device 102 or hardcopy device. The console device 102 also includes a service processor 5vP20.
It also has 7 console functions. after that.

Once the computer system is recovered, the procedure is transferred to the monitoring/maintenance computer system 250.

On the monitoring/maintenance computer system 250 side, the contents of the previous failure and this recovery procedure are stored as a pair in one precedent storage file 254. This will be useful if a similar problem occurs again at another site or your own site later.

Now, details of the fault monitoring device for an information processing system and its control method according to the present invention will be explained using the figures from FIG. 2 onwards.

2 is a diagram showing the configuration of the data buffer 6 shown in FIG. 1, FIG. 3 is a diagram showing the configuration of the comparison table 7, and FIG.・A diagram showing the correspondence of values to register AD2 and data register DT3. FIG.
FIG. 6 shows the format of data when transferring summary information on the occurrence of a fault from the monitoring and control device 100 to the monitoring/maintenance computer system 250. figure.

FIG. 7 shows recovery from the monitoring/maintenance computer system 250 to the monitoring/maintenance computer system 250 when the recovery procedure is transferred from the monitoring/maintenance computer system 250 to the monitoring/control device 100, or after a maintenance worker performs recovery work on site. Figure 8 shows the format of data when transferring procedures, and the format of commands from the console device 102.252 or monitoring/
From the maintenance computer system 250 to the supervisory control device glo.

Figure 9 shows the command format for the supervisory control bag [
FIG. 10 is a diagram showing an example of reducing the amount of data to be transferred when transferring failure information from the computer system 100 to the monitoring/maintenance computer system 250.
4 is a diagram showing the planting of No. 4.

Further, FIGS. 11 to 20 are diagrams showing the processing flow of each processing section. Furthermore, FIGS. 21 and 22 are diagrams explaining automatic recovery operations when no intervention by maintenance personnel is required. 11 is a processing flow diagram of the comparison processing unit CMP5 in FIG. 1, FIG. 12 is a processing flow diagram of the failure determination processing unit 10, and FIG. 13 is a processing flow diagram of the CPU interface processing unit CPUI.
4, FIGS. 14(a) and 14(b) are processing flow diagrams of the diagnostic processing unit 8, and FIGS. 15(a) and (b) are processing flow diagrams of the command interpretation processing unit 13 in the monitoring processing bag [100]. Processing flow diagram, FIGS. 16(a) and 16(b) are processing flow diagrams of the collection/analysis processing unit 23 in the monitoring/maintenance computer system 250,
FIG. 17 is a process flow diagram of the search process of the case law search/registration processing unit 26, FIG. 18 is a process flow diagram of the registration process of the case law search/registration process unit 26, and FIGS. 19(a) and (b) are collation 20 is a processing flow diagram of the recovery instruction generation processing section 27, and FIG. 21 is a processing flow diagram of the processing unit 25, and FIG. 21 is a process flow diagram of the recovery instruction generation processing unit 27. FIG. 22 is a diagram showing an example in which good command sequences are lined up, and FIG. 22 is a diagram showing the processing flow at that time.

Referring to FIG. 2, the data buffer 6 includes a message/command storage area TRACE 6a and a management table 6.
It consists of b. Message/command storage area TR
The ACE 6a includes a field 6c for storing the time at which message data or command data is generated, an identifier field 6d for the message data, a number field 6f for the message data, and a detailed information field 6.
Consists of g. In addition, the management table 6b includes the first area pointer (FIR5T, E) 6h and the last area pointer (LAST) of the message/command storage area TRACE6a.
, E) 6i, current storage area pointer (CUR, E) 6
j, and the next storage area pointer (NEXT, E) 6.

FIG. 3 shows the structure of the comparison table 7, which includes the number of registrations (N) 7a, the message identification T field 7b to be detected, and the message number field 7.
c, and a disposition flag field 7d. The processing flow of the comparison processing unit (CMP) 5 is shown in FIG. (CMP) 5.

Note that the command input from the console [102]
After the data is passed to the computer system 200,
It is sent out again from the computer system 200 as message data.

Referring to FIG. 1, FIG. 2, FIG. 3, and FIG. 11, when messages from the computer system 200, that is, messages of 05208a, are sent out sequentially via 1Lla, the messages shown in FIG. The message data is stored in the data buffer 6 in processing step 31a.

This is the next storage area pointer (NEXT
, E) is stored in the entry shown in 6. When storing.

After setting the time when the message occurred in the time field 6c, the message data is then stored in the message identifier field 6h, message number field 6f,
and stored in the detailed information field 6g. Distribute the stored message data! a11 and is stored in the screen buffer 9, and as a result, the console device 102
displayed on the display screen.

In processing step 31b, the primary storage area pointer (NE
XT, E) 6 and the current storage area pointer (CUR, E)
) 6j are each set to +1.

From processing step 31c to processing step 31f, the value of the above pointer is the final area pointer (LAST, E).
Check whether the value exceeds 6i. If it exceeds, the respective start area pointers (FIR5T, E
)6h value. Therefore, the message/command storage area TRACE 6a of the data buffer 6 can store n pieces of message data, and the message/command storage area TRACE 6a of the data buffer 6 can store n pieces of message data, and can be used from the previous entry of the current storage area pointer (CUR, E) 6j. Therefore, the entries up to the next storage area pointer (NEXT, E) 6k become the history of past message data.

That is, in the case of FIG. 2, (2), (1), and (n).

(n-1)...(5), (4) are past messages
It becomes the history of the data.

In the processing step 31g, the message identifier 6c and the message number 6f of the message data previously stored in the data buffer 6, that is, the message data of the entry pointed to by the current storage area pointer (CUR, E) 6j.
The message identifier 7b and number 7c in the comparison table 7 shown in FIG. 3 are compared. The number of comparisons is the number of registrations (N)
This is the number of times of 7a. As a result of the comparison, if a message equal to the message data of the entry pointed to by the current storage area pointer (CUR, E) 6j is registered in the comparison table 7, it is determined in a determination processing step 31h, The message data and the value of the treatment flag field 7d are passed to the determination processing unit 10 (processing step 31
1. Processing step 31k), if as a result of the comparison there is no matching message data in the comparison table 7, processing step 31 of receiving the next message data;
Return to a.

FIG. 12 is a processing flow when a software failure occurs in the failure determination processing section 10 of FIG. 1, and FIG. 13 is a processing flow of the CPU interface processing section (CPUI) 4 when a hardware failure occurs. Referring to FIG. 12, when control is transferred from the comparison processing unit (CMP) 5, bit 7 of the treatment flag 7e passed as a parameter is checked in a determination processing step 32a to determine whether or not to stop the computer system. Determine. This means that if the value of bit 7 is 1, the computer system will stop. To stop the computer system, it is sufficient to send a signal to the service processor 5VP207 to stop the computer 200 to 1iL1b in processing step 32b.

Next, in processing step 32c, fault summary information 16 shown in FIG. 6 is created. The failure summary information 16 includes a site identifier field 16a, a failure occurrence date and time field 16b, a failure type field 16C1, and a summary information field 1.
It is made up of 6d.

In the case of a software failure, the failure type field 16
The value of c is 'S', and the summary information field 1
6d stores the fault message data. In the processing step 32d, the treatment flag 7d shown in FIG. 3 is prepared as a parameter to the diagnosis processing section 8, and then control is passed to the diagnosis processing section 8 (denoted as DiAG in the flowchart of FIG. 12). At this time, the software failure is expressed as '5OFT'.

When the control is returned from the diagnostic processing unit 8, the occurrence of the failure is notified to the monitoring/maintenance computer system 250 via the transmission/reception processing unit 14 in processing step 32f. At this time, the failure summary information 16 shown in FIG. 6 is transferred to the monitoring/maintenance computer system 250.

Next, we will explain the operation up to the collection of failure information when a hardware failure occurs. FIG. 13 is a processing flow of the CPU interface processing unit (CPUI) 4. When a hardware failure occurs, a notification to that effect is sent to the CPU interface processing unit (CPUI) via the signal line L2 and encoder 1.
)4 will be reported. At this time, data register DT3
holds the reason code for the failure. In processing step 33a, as in the case of software failure,
Create the failure summary information shown in Figure 6. At this time, the value of the failure type field 16c is IH' because it is an eight-doware failure. In addition to the message data at the time of failure occurrence, the summary information field 16d also contains the reason code held in the DT3 in the reason code field 16g.
Store in.

In processing step 33b, the reason code 16e is used as a parameter to the diagnostic processing unit 8, and the next diagnostic processing unit 8 (first
In the flowchart of FIG. 3, the control is passed to DIAG). At this time, the hardware failure is expressed as H'. When the control returns from the diagnostic processing unit 8, the process shown in FIG. Control is then transferred to processing step 32f. The processing at the processing step 32f is performed by the transmitting/receiving processing unit 1 as described above in the software failure processing.
4, the monitoring and maintenance computer system 2508 is notified of the occurrence of a failure. Naturally, at this time the 6th
The failure summary information 16 in the figure is for the monitoring/maintenance computer system 2.
Transferred to 50.

Here, the operation of the diagnostic processing section 8 in FIG. In the event of a hardware failure, control is passed from the CPU interface processing unit (CPUI) 4. In addition, the console family [102 and computer systems for monitoring and maintenance 250
It also operates according to operation commands from. Figure 14(a),
FIG. 14(b) shows a processing flow when the supervisory control device 100 itself detects the occurrence of a failure.

When control is transferred from the failure determination processing unit 10 or the CPU interface processing unit (CPtJI) 4 due to the occurrence of a software failure or a hardware failure, in processing step 34a, each processing unit in the computer system 200 to be viewed is Performs preparation processing to obtain retained logout information.

Here, when the diagnostic processing unit 8 obtains hardware information such as logout information of each processing unit (IU201°Eu2O3, etc.), the address register AD2 in FIG.
．． Set the corresponding value in data register DT3. FIG. 4 shows the bit position number (0=
The value of address register AD2 and data register DT3 corresponding to n-bit bit position number) is shown. Note that the value of address register AD2 corresponds to the number of each processing unit.

1) Command control! Knit (IU) 201. ,． 12) Execution unit (EU) 202 , . 23) Input/output processing unit (IOP), 34) Memory control unit (MCU), 45) Main memory (MS)
,,,56) Service Processor (SVP)
, , 6, the addresses are assigned. Therefore, since the logout information exists in the hardware use area 206b, the value of AD2 is set to 5' corresponding to the MS 206, and the start address is set to DT3.

In the processing step 34b, the collected logout information is stored in the failure information area L8c in FIG.
Identification indicating logout information is set in 8a. Also,
The length of the collected data is set in the number of bytes in the record length 18b. In the next determination processing step 34c, it is determined whether or not there is a software failure. This is the diagnostic processing section 8
As a result of the 0 determination process, which is determined based on the parameters handed over to
Processing step 34m is executed.

On the other hand, software failures, i.e. operating
In the event of a system failure, processing steps 34d to 34i are executed. First.

In the processing step 34d, the number of bits of the treatment flag 7e is set to the number of repetitions (loop number) LOOP.

Also, the value of the counter i is initialized to 0. here,
LOOP, and i are work variables, hardware,
Or, even if it is allocated in the work area within the processing program, it will not work.

Processing steps 34a to 34i are repeated until the value of counter i reaches the value of loop number LOOP. This process examines each bit of the treatment flag focus 7e,
If the value of the bit is '1', then in step 34a of the 0 determination process, hardware information corresponding to that bit position number is collected.

The value of the bit position of action flag bit 7e corresponding to the value of counter i is checked. As a result, if there is no designation, that is, the value is '0', the process advances to step 34i.

On the other hand, t! If the address register AD2. Data register DT3
Set the value to , and start the logout operation of the corresponding processing unit. As shown in Figure 4, this process is based on the value of the counter i corresponding to the diagnosis number and the address
The setting value of register AD2゜data register DT3 is uniquely determined. Next, in processing step 34g, the read hardware information is given the dump identifier 1 shown in FIG.
If the dump identifier 18a is the O8 control table with diagnosis number 1, the dump identifier 18a that is added with the 'O8 control table' and stored in the -time storage file 104 is the identification and execution unit (EU
) 202, the identification of 'EU' is set.

Next, in processing step 34h, the value of counter i is increased by +1.
After that, in processing step 34i, it is checked whether the value of the counter i has reached the value of the loop number LOOP. If not, the process returns to step 34e. When the value of the counter i reaches the value of the loop number LOOP, the operation of the diagnostic processing section 8 ends.

FIG. 14(b) is a processing flow of the diagnostic processing unit 8 when a hardware failure occurs. These series of processes are shown in Figure 14 (
The process is moved from the determination processing step 34c of a). First, in processing step 34k, hardware information is read from each processing unit within the computer system CPU 200. As explained earlier, this process is performed using the address register A.
Each processing unit is activated by setting a value in the D2° data register DT3, but here information on all diagnosis numbers 17a shown in FIG. 4 is collected.

In the next processing step 34m, the dump identifier 18a shown in FIG. 5 is added to the read hardware information and stored in the -time storage file 104.

As described above, the computer system 200 to be monitored and controlled
When the operation at the time of a failure occurs, that is, the notification to the monitoring/maintenance computer system 250 and the failure information collection operation are completed, the monitoring/maintenance computer system 250 instructs to dispatch maintenance personnel to the site.

Failure factor analysis 1 Start operations such as automatic generation of recovery measures.

Before explaining these operations, the monitoring and control device i! 10
Command interpretation processing unit 13. The operation of the transfer processing unit 12 will be explained.

FIG. 8 shows the format of commands input from the console device 102.252 and the format of commands issued from the computer system 250 for monitoring and maintenance. The command interpretation processing unit 13 in the monitoring/control device 100 can also be operated by manually inputting commands from the console device IO2, the console device 252 of the computer system 250 for monitoring/maintenance, and the computer system for monitoring/maintenance. It is also possible to operate by automatically generating and sending a command data stream from the collection/analysis processing unit 23 in 250. The list of commands shown in FIG. 8 is an example of the present invention, and additions can be made.

15(a) and 15(b) show a processing flow corresponding to the command in FIG. 8. After obtaining the command data stream in processing step 35a, processing branches to processing corresponding to each command in processing step 35b.

(1) GETMSG This command is sent to data buffer 6 (symbol 6a in Figure 2).
) is stored in the temporary storage file 104 from the area pointed to by the pointers NEXT and E6 to the area immediately before the area pointed to by the pointers CUR and Eej (processing step 35c).

(2) GETHARD This command is a command for obtaining hardware information of each processing unit in the computer system 200, and is used to start the diagnostic processing unit 8 described above to perform processing, and is executed in processing step 35d. -Processing step 35f is executed.

(3) GETLOG This command is also a command for obtaining hardware information of each processing unit in the computer system 200.
In particular, the hardware holding information of each processing unit (diagnosis numbers 3 to 6 in FIG. 4) is collected. For this purpose, processing step 35g is operated, and similarly to (2), the 5-diagnosis processing section 8 is activated to perform the processing.

(4) ACTION This command outputs the data string of the failure recovery procedure sent from the monitoring/maintenance computer system 250 to an output device such as a display device of the console device 102 or a hard copy device (processing step 35h). FIG. 7 shows the format of the data string 19 of the failure recovery procedure, and a series of recovery procedures are stored in the recovery procedure field 19c.

(5) RECOVER This command is used when a recovery procedure cannot be generated on the monitoring/maintenance computer system 250 side and maintenance personnel are on-site using trial and error to recover a failed computer system. It is used when transferring procedures to the monitoring/maintenance computer system 250. In step 35i, this process sequentially inputs the recovery procedure input from the console device 102 into the recovery procedure field 19c in FIG.
After completing the other fields 19a to 19d, the data is transferred to the monitoring/maintenance computer system 250 via the transfer processing unit 12.

(6) SUMMARY This command is used to display summary information of the failure occurrence shown in FIG. Console equipment for monitoring and control equipment for a computer system that has failed! 102, the fault summary information 16 of FIG. 6 is displayed on the display screen of the console device 102 in processing step 35j. On the other hand, when a command is issued from the console device 252 of the monitoring/maintenance computer system 250 or the collection/analysis processing section 23, the fault summary information 16 shown in FIG. 6 (7) TRANSFER to the computer system 250 This command transfers the failure information stored in the temporary storage file 104 to the computer system 250 by processing step 35m. Note that at this time, the transfer processing unit 1
2, as shown in FIG.
Do 2a. That is, when the same data string continues with the failure information 28a, the symbol 1 28c is inserted and a new data string 28b is transferred. As a result, line L in Figure 1
This has the effect of reducing the amount of data passing through 4.

(8) DISPLAY This command is used by local maintenance personnel to display failure information stored in the temporary storage file 104 using the console device 102, or to display it on the console device 252 of the computer system 250 for monitoring and maintenance. It is used when you want. Specifically, in processing step 35n, the contents of the -time storage file 104 and data buffer 6 are displayed on the relevant console device.

The above is the operation of the command interpretation processing unit 13.2In addition, in the command processing described above, (4) ACTION
In the command processing, an embodiment is disclosed in which a recovery procedure is displayed to maintenance personnel in processing step 35h;
Regarding recovery that does not involve replacing hardware parts, it may be possible to recover without requiring any operations by maintenance personnel. The embodiment will be described later with reference to FIG. 21 and subsequent figures.

Next, the operation when the monitoring/maintenance computer system 250 receives a notification of the occurrence of a failure from the monitoring control device will be described. To report the occurrence of a failure, use the failure summary information 1 shown in Figure 6.
6 is received by the 1 communication processing section 21 via the line L4, and the control is passed to the collection/analysis processing section 23.

FIG. 16(a) shows the processing flow when a fault report is received in the collection/analysis processing unit 23.6 First, in processing step 36a, the received fault summary information 16 is
UF24. and stored in the failure information file 256.

Maintenance personnel may be dispatched to the site at this point, or may be dispatched when the recovery procedure is determined in the subsequent processing step 36d. Next, in processing step 36b, the TRANSFER command explained in FIG. 8 is issued to the supervisory control device 100, and detailed failure information is collected. The collected fault information is temporarily stored in the fault information file 256 in processing step 36c.

Next, the failure summary information 16 is passed to the precedent search/registration processing unit 26, and control is also transferred. In FIG. 16(a).

It is written as STG. Note that in this case, it becomes a 'search' request. The case precedent search/registration processing unit 26 stores past failure cases similar to the failure summary information 16 in the case precedent storage file 254.
, and store it in BUF24. This process is
This will be explained later using FIG. 17. Past failure cases are BUF
24, the primary verification processing unit (EXTR) 25
Start.

This matching processing unit (EXTR) 25 compares detailed fault information from among the candidate groups, and if a match is found, the control is returned together with the case, and if there is no matched fault example, it is determined that there is a 'mismatch'. Return control with this message.

If it matches a past failure example, the recovery instruction generation processing unit 27 is activated to generate a recovery procedure. Figure 16 (
In a), the recovery instruction generation processing unit 27 is expressed as GEN. The recovery instruction generation processing unit 27 generates recovery information 19 shown in FIG.

Therefore, the collection/analysis processing unit 23 transfers the recovery information 19 to the monitoring device 100 in processing step 36d.

On the other hand, if it did not match the past failure cases.

In order to newly register the currently occurring failure in the precedent storage file 254, the precedent search/registration processing unit (STG) 26
Start. In this case, the word ``registration'' will be written.

During this registration process, the recovery procedure is stored without being specified, but when one recovery procedure is later found out, or when recovery is performed on-site, maintenance personnel can input the RECOVER command shown in Figure 8. 1 Recovery procedure is completed.

When the case law search/registration processing unit (STG) 26 completes registration of the failure example, control returns to the collection/analysis processing unit 23 again.

In the collection/analysis processing unit 23, 1
A mark indicating that the recovery procedure could not be generated is stored in the recovery procedure field 19c in FIG. 7, and the data string 19 is sent to the supervisory control device i! Transfer to 100. Thereafter, processing step 36
At step g, a message indicating that the recovery procedure could not be generated is also displayed on the console device 252 of the monitoring/maintenance computer system 250, and the wisdom of an experienced person is requested. Therefore, in processing step 36h, the expert uses the console device 25.

While inputting the commands shown in FIG. 8, the failure will be analyzed and a recovery procedure will be explored. At this time, local maintenance personnel are also searching for recovery procedures.

As a result, they will be considered in parallel. If the monitoring/maintenance computer system 250 side obtains the recovery procedure quickly, the recovery information 19 in FIG.
Transfer to.

FIG. 16(b) shows the registration process of the recovery procedure in the collection/analysis processing unit 23. The recovery procedure is the monitoring control device 1.
REC from the console device ff1102 on the 00 side in Figure 8
:0VER command may be input, or may be input from the console device 252 of the monitoring/maintenance computer system 250. In addition.

Interpretation command processing unit 2 of monitoring/maintenance computer system 250
The operation of No. 2 may be considered to be basically the same as that of the command interpretation processing section 13 on the supervisory control device 100 side.

In processing step 36i, the 0th and 1st case search/registration processing unit (STG) 26 that obtains the recovery information 19 in FIG. 7 is activated to complete the failure case for which the recovery procedure has not yet been completed.

Next, using FIG. 10 and FIGS. 17 to 20, 1 case law search/registration processing section 26. The operation of the verification processing section 251 and the recovery instruction generation processing section 27 will be explained. FIG. 10 shows the structure of the case storage file 254. In the case storage file 254, hardware failures and software failures are stored separately. This is to speed up the search and is not intended to be stored in a separate file the next day. Referring to FIG. 10, in the case storage file 254, hardware failures and software failures are managed by the management table 30, and regarding hardware failure cases, the number of hardware failure registrations (K
) 30a and storage area pointer (H) 30b are stored. In addition, the entity of the precedent is stored in the storage area pointer (
H) Pointed to by 30b. One case law information 29 includes a reason code 29a, a failure message 29b, a related message 29c, a Ji prisoner rough field 29d failure information 29
It consists of f, recovery procedure 29g, and statistical information 29h. Here, the reason code 29a stores the reason code 16e in the failure summary information 16 in FIG. 6, and the failure message 29b
A fault message field 16d is also stored. The related message 29c stores a message related to the fault message 29 or a message that caused the fault message 29 in the CU of the data buffer 6 in FIG.
The search is performed backwards from the message indicated by R, E (6j), and the corresponding message is stored in the area 29c. Further, the failure information 29f stores information collected at the time of occurrence of the failure described above.

The recovery procedure field 29g stores a recovery procedure performed for the failure, such as the recovery procedure field 19c in FIG. 7. The statistical information 29h stores statistical information such as the number of times the failure occurs.

On the other hand, regarding software failure information, the entity is managed in the management table 30 by the number of software failure registrations (L) 30C and the storage area pointer (S) 30d, and one case law information 41 in the entity is the reason. Same as hardware fault information except that no code is present.

FIG. 17 is a processing flow of the search process of the case law search/registration processing unit (STG) 26. Referring to Figure 7, first,
In processing steps 37a and 37b, the summary information 16d of the failure summary information 16 in FIG. Here, the reason code 29a is compared in the case of a hardware failure, and the failure message 41b is compared in the case of a software failure. As a result of the comparison, if an entry equal to the failure summary information 16 is found, in processing step 37c, this entry is stored in the BUF 24 as one of the candidates. Judgment process - step 37
d, process step 3 until all entries are retrieved.
7a through processing steps 37c are repeated. By the above,
Candidates corresponding to the failure summary information 16 are stored in the BUF 24.

Thereafter, the matching processing unit 25 extracts precedents that match the fault that has occurred.

FIG. 18 is a processing flow of the registration process of the precedent search/registration processing unit (STG) 26. First, determination processing step 38
In a, it is determined whether failure information or recovery information is to be registered. If failure information is registered, processing step 38
b is executed, and if the recovery information is registered, processing step 38C2 is executed, processing step 38d is executed. When registering fault information, the fault summary information 16 and detailed information shown in FIG. 6 are divided into hardware faults/software faults and stored in the information area 29 or the information area 41 in processing step 38b. On the other hand, if recovery information is to be registered, case information 29 or case information 41 corresponding to recovery information 19 in FIG. 7 is searched. Next, the recovery procedure 19c of FIG. 7 is stored in the recovery procedure 29g or recovery procedure 41g of the searched case information 291 and case information 41.

FIGS. 19(a) and 19(b) are processing flow diagrams of the collation processing section 25 of FIG. 1. In processing step 39a, it is determined whether the failure is a hardware failure or a software failure. If checking for hardware failure,
Processing step 39i to processing step 3 in FIG. 19(b)
Execute 9p. If it is a comparison of software failure cases, processing steps 39b to 39h are executed.

First, in processing step 39b, the number of precedent candidates stored in the BUF 24 is set to the work variable Count.Next, a counter i is initialized to zero.

Here, the work variable Count and the counter are the fourteenth
As in Figure (a), it may be secured in hardware or in a work area.

After incrementing the counter i by 1 in processing step 39c, the value of counter i is changed to the work variable Coun in processing step 39d.
It is determined whether the value of t has been exceeded.

If the value of the counter i exceeds the value of the work variable Count, it means that there is no precedent that matches the failure, and the mismatch ends. If the value of the counter i does not exceed the value of the work variable Count, it is determined in determination processing step 39e whether or not the failure messages 41b are equal. If they do not match, the process returns to step 39c. Next, in determination processing step 39f, it is determined whether the related messages 41c are equal. If they do not match here as well, the process returns to step 39c. If the failure message 41b and related message 41c also match, judgment processing step 3
At step 9g, it is checked whether the failure information 41f matches. As a result, if they do not match, the process returns to step 39c. On the other hand, if there is a match, the recovery procedure 41g for the entry indicated by the counter i is passed to the processing section that called the main verification processing section 25, that is, the collection/analysis processing section 23, in processing step 39h, and the matching ends. At this time, the number of failure occurrences in the statistical information 41h is incremented by 1.

FIG. 19(b) shows a process of collating precedents for hardware failures. First, in processing step 39j, the work variable Cou
The number of case precedent candidates stored in the BUF 24 is set in nt. Next, counter i is initialized to 0. Next, in processing step 39k, counter i is incremented by 1, and then in processing step 39m, the value of counter i is changed to the work variable Coun.
It is determined whether the value of t has been exceeded. If the value of the counter i exceeds the value of the work variable Count, it means that there is no precedent that matches the failure, and the mismatch ends. If the value of counter i does not exceed the value of work variable Count, reason code 29 is determined in judgment processing step 39n.
Determine whether a is equal. - If not, the process returns to step 39. Next, in determination processing step 390, it is checked whether the failure information 29f matches. the result,
If they do not match, the process returns to step 39. On the other hand, if they match, in a processing step 39p, the recovery procedure 29g of the entry indicated by the counter i is passed to the processing unit that called the main matching processing unit 25, that is, the collection/analysis processing unit 23,
The match ends. At this time, the number of failure occurrences in the statistical information 29h is incremented by 1.

The above is the operation of the collation processing section 25 shown in FIG.

Next, the operation of the recovery instruction generation processing section 27 will be explained.

FIG. 20 is a processing flow diagram of the recovery instruction generation processing section 27. First, in the processing step 40a, the case law information 29 or the case law information 41 collated and selected in the BUF 24
Recovery procedure: Obtain 29g or 41g. In the next processing step 40b, failure recovery information 16 shown in FIG. 7 is created.

Namely.

The recovery procedure 29g or 41g obtained in processing step 40a is stored in field L9c.

Note that fields 19a to 19b in FIG. 7 are obtained by copying fields 19a to 16b in FIG. 6. Also, recovery date and time field 1
In 9d, the date and time at which the recovery procedure was generated in this processing step is set.

Next, an explanation will be given of an automatic recovery operation when maintenance personnel's intervention 1, for example, replacement of a hardware package is not required on the supervisory control device 100 side. FIG. 21 shows the recovery procedure field 19c of the recovery information 19 shown in FIG.
An example is shown in which a data string 45b of console device operations to be performed at the time of standard restart of the computer system is stored. FIG. 22 shows the processing flow of the command interpretation processing section 13 at this time. In addition to the command list shown in FIG. 8, the command interpretation processing unit 13 also receives recovery information 19 sent from the monitoring and maintenance computer system 250.
All you have to do is check the contents and operate. First, process step 4.
At step 3a, the computer system 200 to be controlled is stopped and a system reset command is issued in response to the command sequence 44 in FIG. This is done by storing command data for the above operations in the data buffer 6.

Service processor S V P 20 via line Llb
In the zero-order judgment processing step 43b sent to Step 7, the data 45a is examined to check whether or not it is a standard restart. The data string 45b is output to the console device 102, hard copy device, or the like.

If standard restart is specified, process step 43
At step c, the data string 45b of the recovery procedure is transferred to the data buffer 6.
, stored in the screen buffer 9. As a result, the data string 45b is also displayed on the console device 102, and the line Lla.

Service processor 5VP207 and operating system ○52 of computer system 200 via Llb
It can be handed over to 08a.

〔Effect of the invention〕

According to the present invention, in order to monitor and recover from failures in computer systems, a supervisory control device is present on the side of the computer system to be controlled, and constantly monitors the behavior of the computer system, and when a failure occurs, Fault information is automatically collected and transferred to a remote monitoring and maintenance computer system. When a computer system for monitoring and maintenance receives a notification of a failure, it immediately dispatches maintenance personnel, and by comparing the failure information with past failure precedents, it generates appropriate recovery measures and sends them to the maintenance personnel who arrive at the site. Since the instructions are automatically given, the time from the occurrence of a failure to the recovery of the computer system I- can be significantly shortened.

Furthermore, for failures that do not require intervention by maintenance personnel,
Since the computer system is automatically restarted, this has the effect of bringing one step closer to realizing unmanned driving services.

Furthermore, since the remote monitoring and maintenance computer system monitors the occurrence of failures in multiple computer systems, it has the effect of allowing a small number of people to operate many computer systems.

Furthermore, remote monitoring and maintenance computer systems provide failure information when failures occur in multiple computer systems.

Since the information and recovery methods are stored all at once, it is possible to accumulate failure management information.

[Brief explanation of the drawing]

FIG. 1 is a diagram showing the characteristic configuration of the fault monitoring device and control method of the information processing system of the present invention, FIG. 2 is a diagram showing the configuration of the buffer 6 in FIG. 1, and FIG. 3 is a comparison table. 7 shows the configuration of the diagnostic number and address register (AD) 2.7 used in the diagnostic processing unit 8. FIG. 5 is a diagram showing the correspondence of values to the data register (DT) 3, and FIG. FIG. 6 is a diagram showing the format of data when transferring summary failure information from the monitoring and control device 100 to the monitoring and maintenance computer system 250, and FIG. When transferring the recovery procedure from the maintenance computer system 250 to the monitoring and control device 100, or after a maintenance worker performs recovery work on site, the monitoring and control device 10
FIG. 8 is a diagram showing the format of data when transferring the recovery procedure from the computer system 250 for monitoring and maintenance from the computer system 250 for monitoring and maintenance. A diagram showing the format of a command to the control device 100, FIG. 9 is a diagram showing the format of a command to the control device 100.
Figure 10 is a diagram showing the structure of the precedent storage file 254, and Figure 11 is a comparison of Figure 1. 12 is a processing flow diagram of the processing unit (CMP) 5, FIG. 12 is a processing flow diagram of the failure determination processing unit 10, and FIG. 13 is a processing flow diagram of the CPU interface processing unit (CPUI) 4.
4(a) and (b) are process flow diagrams of the diagnostic processing unit 8, and FIG. 15(a). (b) is the command interpretation processing unit 1 in the supervisory control device w100.
3, FIGS. 16(a) and 16(b) are process flow diagrams of the collection/analysis processing unit 23 in the monitoring/maintenance computer system 250, and FIG. A process flow diagram of the search process, FIG. 18 is a process flow diagram of the registration process of the case law search/registration processing unit 26, and FIG.
(b) is a processing flow diagram of the collation processing section 25, FIG. 20 is a processing flow diagram of the recovery instruction generation processing section 27, and FIG. 21 is a processing flow diagram of the recovery instruction generation processing section 27.
FIG. 22 is a diagram showing an example in which a data string of console device operations performed at the time of standard restart of a computer system is stored in the recovery procedure field 19c of the recovery information 19 shown in 1. 3 is a diagram showing a processing flow in a command interpretation processing unit 13. FIG. 1...Encoder, 2...Address register (A
D). 3... Data register (DT), 4... CPU interface processing section, 5... Comparison processing section (CMP),
6...Data buffer, 7...Comparison table, 8
...Diagnosis processing unit, 9...Screen buffer, 1o...
Failure determination processing section, 11... Distributor, 12... Transfer processing section, 13... Command interpretation processing section, 14... Transmission/reception processing section. 21... Communication processing section, 22... Interpretation command processing section, 2
3... Collection/analysis processing unit, 24... Work buffer BUF. 25... Collation processing unit, 26... Case law search/registration processing unit, 27... Recovery instruction generation processing unit, 100... Monitoring control device, 102... Console device, 104...
- Time storage file, 200... Information processing system (computer system) to be monitored and controlled, 250... Computer system for monitoring and maintenance, 252... Console device, 2
54... Judgment memory file. 256... Failure information storage file. Figure No. 1 Concave (d Fig. 6 (b) No. ?'ff Fig. 9 Fig. (a,) 5 Kuzu Z/ Fig. 7

Claims (1)

[Scope of Claims] 1. At least one central processing unit having a main storage device, a group of input/output devices, a function of a console for maintenance operations of the central processing unit, and an operation under the central processing unit. a first information processing system equipped with a console function that allows message display and input of commands for an operating system; and a second information processing system that monitors and controls the operation of the first information processing system from a remote location. In the system configuration, a first storage means for storing a certain number of message data of an operating system of the first information processing system or command data input from a console display device; and a first storage means for detecting an abnormal state. a second storage means for storing message data of the operating system; a first comparison means for comparing message data of the operating system with the contents of the second storage means; and a first comparison means for comparing the contents of the second storage means as a result of the comparison. If they match, the control means notifies the second information processing system at the remote location of the occurrence of a failure, and the content of the first storage means is stored in the second information processing system at the remote location based on the command from the second information processing system at the remote location. 2. A fault monitoring device and control method for an information processing system, characterized by comprising a control means for sending out data to the information processing system. 2. At least one central processing unit with a main memory, a group of input/output devices, the functions of a console for maintenance operations of the central processing unit, and the messages of an operating system operating under the central processing unit. In the configuration of a first information processing system equipped with a console function that enables display and input of commands, and a second information processing system that monitors and controls the operation of the first information processing system from a remote location, A control means for receiving a signal indicating that a hardware failure has occurred in the central processing unit of the first information processing system; a control means for notifying a second information processing system at a remote location of the occurrence of a failure; A control means for reading out the state of hardware of a central processing unit in the first information processing system based on a command from the second information processing system, and a control means for sending the read information to the second information processing system. A fault monitoring device and control method for an information processing system, characterized by the following. 3. At least one central processing unit with a main memory device, a group of input/output devices, the functions of a console for maintenance operations of the central processing unit, and the messages of an operating system operating under the central processing unit. In the configuration of a first information processing system equipped with a console function that enables display and input of commands, and a second information processing system that monitors and controls the operation of the first information processing system from a remote location, When the second information processing system receives a report of the occurrence of a failure in the first information processing system, the contents of the first storage means or the hardware of the central processing unit in the first information processing system A fault monitoring device and control method for an information processing system, characterized in that a second information processing system is provided with a control means for obtaining the status. 4. At least one central processing unit having a main memory, a group of input/output devices, the functions of a console for maintenance operations of the central processing unit, and the messages of an operating system operating under the central processing unit. In the configuration of a first information processing system equipped with a console function that enables display and input of commands, and a second information processing system that monitors and controls the operation of the first information processing system from a remote location, When a failure occurs in the first information processing system and the second information processing system obtains failure information of the first information processing system, a third information processing system that stores failure precedents in the second information processing system control means for comparing the failure information of the storage means and the first information processing system with the precedents in the third storage means; and as a result of the comparison, if a matching failure precedent exists, A fault monitoring device and control method for an information processing system, characterized by comprising a control means for generating a processing procedure for recovering from a fault. 5. The recovery processing procedure obtained by the control means that generates the processing procedure for recovering from a failure in the first information processing system as described in claim 4 is performed by maintenance personnel who By inputting a command to refer to the recovery processing procedure from the console/display device of the system, the control means transmits the recovery processing procedure from the second information processing system, and the received recovery processing procedure is sent to the second information processing system. 5. A fault monitoring device and control method for an information processing system according to claim 4, further comprising a control means for displaying information on a console display device of the first information processing system. 6. The contents of the second storage means recited in claim 1 are stored on a console connected to the first information processing system.
Claim 1, characterized by comprising a control means that can be changed according to an instruction from a display device or a control means that can be changed according to an instruction from a second information processing system.
Fault monitoring device and control method for the information processing system described in Section 1. 7. The signal indicating the occurrence of a failure as set forth in claim 2 is generated by a specific monitoring program running under the first information processing system constantly inspecting the state of the hardware;
As a result, a fault monitoring device for an information processing system according to claim 2, further comprising a control means for executing a command to generate a signal indicating the occurrence of the fault when an abnormality is detected. Control method. 8. The signal indicating the occurrence of a failure as set forth in claim 2 indicates that a hardware monitoring mechanism operating under the first information processing system detects an abnormality in the operating state of the hardware. 3. A fault monitoring device and control method for an information processing system according to claim 2, further comprising a control means for executing an instruction to generate a signal indicating that the fault has occurred. 9. The control means for reading the state of the hardware according to claim 2 is held by the control means for addressing each processing unit of the central processing unit and each addressed processing unit. 3. A fault monitoring device and control method for an information processing system according to claim 2, characterized in that the device comprises a control means that receives the state of the hardware via a dedicated data line. 10. In the control means for reading out the state of the hardware according to claim 2, for the main storage device,
3. A fault monitoring device and control method for an information processing system according to claim 2, further comprising means for reading out data in a special area that cannot be accessed by an operating system. 11. In the control means for reading the state of the hardware according to claim 2 or 10, the storage area address in the main storage device is sent to the main storage device, and the corresponding data is sent to the main storage device. A fault monitoring device and control method for an information processing system according to claim 2 or claim 10, characterized by comprising a control means for obtaining the following. 12. The hardware state information read by the control means for reading out the hardware state according to claim 2, 10, or 11 is stored in the fourth storage means. Claim 2, or 10, or 11, characterized in that the claim comprises a control means for
Fault monitoring device and control method for the information processing system described in Section 1. 13. The system is characterized by comprising a control means for editing and sending the fault information as set forth in claim 1 or 2 when the fault information is sent to the second information processing system. A fault monitoring device and control method for an information processing system according to claim 1 or 2. 14. The editing means described in the preceding paragraph is characterized in that when editing the contents of the first storage means, the processing step consists of extracting only message data from the operating system and command data from the console display device. A fault monitoring device and control method for an information processing system according to claim 13. 15. In the editing means according to claim 13, when editing the hardware information, the control means edits the contents of the fourth storage means, and when editing the contents of the main storage device, the same data is contiguous. 14. The fault monitoring device and control method for an information processing system according to claim 13, further comprising a processing step of replacing the fault with data indicating that fact. 16. The information processing system as set forth in claim 4, wherein the third storage means as set forth in claim 4 stores phenomena and causes of failure occurrence, and recovery history. fault monitoring device and control method. 17. As a result of checking with the third storage means described in claim 4, if no matching precedent is found, the phenomenon of the occurrence of the failure is added to the third storage means as a new failure precedent. 5. A fault monitoring device and control method for an information processing system according to claim 4, further comprising a control means for storing the information. 18. If no matching precedent is found as a result of checking with the third storage means described in claim 4, the maintenance personnel will later perform the recovery processing procedure from the console display device of the first information processing system. The method includes a control means for displaying that no case law is found when a reference command is input, and a processing means for displaying the contents of the first storage means and the fourth storage means on a console display device. A fault monitoring device and control method for an information processing system according to claim 5. 19. As a result of checking with the third storage means recited in claim 17, if no matching precedent is found and the cause of the failure and the recovery procedure are later found, the cause of the failure and the recovery procedure 18. The fault monitoring device and control method for an information processing system according to claim 17, further comprising a control means for correcting and storing the corrected data in the third storage means in response to a fault phenomenon. 20. As a result of checking with the third storage means described in claim 4, if no matching precedent is found, the second storage means
Information according to claim 5, characterized in that the display output device of the information processing system is equipped with processing means for displaying and outputting the failure information obtained from the first storage means and the fourth storage means. Processing system failure monitoring device and control method. 21. At least one central processing unit having a main memory, a group of input/output devices, the functions of a console for maintenance operations of the central processing unit, and the messages of an operating system operating under the central processing unit. In the configuration of a first information processing system equipped with a console function that allows display and input of commands, and a second information processing system that monitors and controls the operation of the first information processing system from a remote location,
When a failure occurs in the first information processing system and the second information processing system obtains failure information of the first information processing system, a second information processing system that stores failure precedents in the second information processing system; If there is a matching fault case as a result of the comparison, the first information processing system is
a control means for generating a processing procedure for recovering from a fault in the information processing system;
The control means for transferring the information to the control device monitoring the information processing system and the control device monitoring the first information processing system restart the first information processing system based on the recovery processing procedure. A fault monitoring device and a control method for an information processing system, characterized by comprising a control procedure for controlling the same. 22. At least one central processing unit having a main memory, a group of input/output devices, the functions of a console for maintenance operations of the central processing unit, and the messages of an operating system operating under the central processing unit. In the configuration of a first information processing system equipped with a console function that allows display and input of commands, and a second information processing system that monitors and controls the operation of the first information processing system from a remote location,
Claims 1, 2, or 3, characterized in that the second information processing system is equipped with a control means that can monitor and control the operations of the plurality of first information processing systems, or A fault monitoring device and control method for an information processing system according to item 4 or 21.