JPH07262021A - System recovery system - Google Patents

Abstract

PURPOSE:To realize the shortening of recovery time and a recovery work by batch job to a disk fault to cause operating system(OS) down to be generated at a system distributedly arranging regular (normal) OS environments. CONSTITUTION:A driver OS environment 4 for recovery is made to coexist in the disk 1 of a regular OS. When any hardware fault is generated, as a recovery method in the down state of the OS, the system is started by the OS dedicated disk while using the OS environment for recovery set to the OS dedicated disk, and the disk generating the fault can be recovered by the batch job.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a system recovery system, and more particularly to a system recovery system for recovering a system using a one-pack OS when a disk failure occurs that causes a system down.

Further, the present invention is a simple system recovery system for starting a system for investigating a failure for system recovery when a disk required for booting the system by the IPL operation fails. Regarding

[0003]

2. Description of the Related Art When a conventional operating system (hereinafter referred to as OS) is down due to a disk failure, it is general to use a stand-alone tape or a driver OS as a one-pack OS.

FIG. 5 shows the relationship between a normally used OS dedicated volume and an OS environment volume. OS shown in the figure
The dedicated volume 10 stores an OS entity that performs an IPL operation for starting up the system. The OS environment volumes 11 _{1 to} 11 _n have an environment (data set) necessary for operating the OS. It is distributed over multiple disks to reduce the load on one. Also,
The one-pack OS 20 is provided as a stand-alone tape or a driver outside the OS-dedicated volume 10.
When the S dedicated volume 10 is down, the engineer inputs the one-pack OS 20 to perform the system function.

FIG. 6 shows the structure of the one-pack OS. The one-pack OS 20 shown in FIG.
1, page function 22, spool function 23, user management unit 24, RACF management unit 25, SYS1, STGINDE
It is composed of an OS program for booting only the system when a failure such as X26 occurs.

For example, the spool function converts input / output information into a magnetic disk by using multi-programming. In the page function, information overflowed by a failure is stored page by page in another storage device. The checkpoint function stores various counters, tables, status words, etc. in the main storage device of the computer system in the magnetic medium at regular intervals or at regular transaction counts in order to speed up recovery from failures. The user management record stores the users who were using the computer at the time of the failure.

As described above, the one-pack OS 20 is set only with the OS program required only for initial start-up, and does not have the function of the OS program that covers all general business operations. Is intended to do.

FIG. 7 is a diagram for explaining a case where an OS is booted when a disk fails in a conventional network. In the figure, among the general-purpose machines 100 _{1 to} 100 _n existing in the network 200, the general-purpose machine 100 ₃
Suppose that the system went down. In this case, the general-purpose machine 1
Notify the center of the occurrence of failure No. 00 _{3 and} the general-purpose machine 1
A field engineer located near 00 ₃ externally loads the one-pack OS 20 into the general-purpose machine 100 ₃ . When the one-pack OS is stored in the stand-alone tape, the OS is read from the magnetic tape reader to perform the IPL operation and start up the system of the general-purpose machine 100 ₃ . As a result, when the system startup is successful, the cause of the failure is investigated using the failure investigation program of the environment OS for normal surroundings.

[0009]

However, in the above-mentioned conventional method, a stand-alone tape or a one-pack OS of the driver OS managed by the field engineer in charge of the faulty general-purpose machine is managed outside the general-purpose machine. When the system is started up, its operation is complicated, and there is a problem that recovery by a batch job cannot be performed. Further, in the method using the driver OS, it is necessary to prepare a disk in which the normal driver OS resides, and the maintenance work of the OS must be performed twice, that is, the regular driver OS and the one-pack OS. There is also.

The present invention has been made in view of the above points, and solves the above-mentioned problems of the prior art, and against a disk failure that leads to an OS down occurring in a system in which a regular (normal) OS environment is distributedly arranged. It is an object of the present invention to provide a system recovery system and an operating switching system that can reduce recovery time / recovery work by batch jobs.

[0011]

FIG. 1 is a block diagram showing the principle of the present invention.

The system recovery system of the present invention coexists with an operating system (hereinafter referred to as OS) environment 4 for recovery in a disk 1 of the OS to perform recovery when a failure occurs.

The capacity of the recovery driver OS environment is set according to the free capacity of the disk 1 of the regular OS.

[0014]

The present invention provides a recovery method for a system in which a part of the OS environment is located on a business-use disk and the OS is down when a hardware failure occurs on the business-use disk. By using the recovery OS environment set in the OS-dedicated disk, the system can be started up in the OS-dedicated disk, and the disk in which the failure has occurred can be recovered by the batch job.

Furthermore, the present invention is further developed, and a recovery OS is provided.
The contents of the master catalog for use are not limited to the recovery, but by creating an OS program for system creation or system maintenance, the program broken by a failure can be corrected or the broken program can be discarded to create a new O
It is also possible to configure the S program.

[0016]

Embodiments of the present invention will now be described in detail with reference to the drawings.

The configuration shown in FIG. 1 above is based on the OS environment 1
Is partly allocated to the business-use disk 2. When a hardware failure occurs in the business system disk 2, the OS goes down. As a system recovery method from this state,
A system for booting the OS-dedicated disk 1 is enabled by using the recovery OS environment 4 set in the OS-dedicated disk 1, and the failed disk 2 is recovered by a batch job.

FIG. 2 is a schematic diagram of a system according to an embodiment of the present invention.
The disk layout is shown. The disk system shown in FIG.
S dedicated disk 1 and business disk 2₁~ 2_nBy
Is made. Of these, the OS-only disk 1 is
It is stored. Checkpoint data for recovery
Data set, spool data set, paging data
A data set such as a set is empty in the OS-dedicated disk 1.
It can be set in the recovery OS environment area 4, which is the storage area. However
Then, according to the amount of data processed in the regular OS environment 3,
The capacity of the cover OS environment area 4 changes. In addition,
Paging data set,
Operational disk 2 for pool dataset ₁~ 2_nDistributed in
It is arranged.

The functions set in the OS recovery area 4 are the same as those of the conventional one-pack OS. The recovery OS has the purpose of activating a system in order for the service engineer to investigate the failure and diagnosing and recovering the disk when a failure occurs in the system, for example, the business disk 2.
It does not require an environment of a sufficient size for operating the functions of the OS required for business processing.

The shaded portion of the OS-dedicated disk 1 shown in FIG. 2 is the portion set as the recovery OS environment. In addition to the OS program, the OS main body 3 includes a regular OS master catalog 3, a regular OS master catalog 3, and a recovery OS master catalog 44.
There is a shared system data set 8 which selects the catalog of. The recovery OS environment area 4 includes a recovery OS master catalog 44 and a recovery O.
PAGE 46 for S, SPOOL 47 for recovery OS, etc. are set. However, the system parameter data set 5
The shared system data set group 8 is commonly used by the normal OS master catalog 3 and the recovery OS master catalog 44.

Next, an outline of the operation of the configuration shown in FIG. 2 will be described.

In normal times, the OS is a normal OS master catalog 3, a shared system data set group 8, a normal OS parameter 5, and pages (PA) arranged on the business system disk 2.
GE) or spool (SPOOL) datasets and other environmental disks.

On the other hand, when a hardware failure that brings down the official OS occurs in the disk 2 in which the OS environment is distributed, the recovery OS master catalog 44,
The shared system data set 8, the recovery OS parameter 45, the recovery OS spool 47, the page data set 46, etc. are used to start up the OS-dedicated disk 1 and recover the failed disk 2.

FIG. 3 is a flow chart showing the operation of the embodiment of the present invention up to the recovery from a failure. First,
When the business-use regular OS disk 2 of the general-purpose system in the network goes down (step 100), a notification that a failure has occurred is sent to the network center. This notification method may be an existing notification method (step 101). When the center receives the system failure notification, it instructs the general-purpose system in which the failure has occurred to retry (step 102). If retry is possible, the failure information is directly stored in the access storage device or the like, and the task is executed as it is. If it is executed and the same failure information occurs, the process may proceed to step 103 (step 103). If the retry fails in step 102, the OS is started using the recovery data sets (environments) 46 and 47 set in the recovery OS environment 4 in the OS disk 1 (step 104). If the system where the failure occurs is started up (step 105, Yes), it is connected to the network (step 1
06), processing for failure recovery such as failure diagnosis is performed (steps 107 and 108). On the other hand, OS disk 1
If the system does not start up even if the recovery function inside is activated (step 105, No), step 10
Move to 2 and try again from retry.

FIG. 4 shows a recovery O according to an embodiment of the present invention.
It is a figure for explaining starting of S. Perform the first IPL operation. At this time, it is determined whether to use the one-pack OS 4 for recovery. When performing a normal IPL operation, specify "SYS1.MCAT01" when selecting a catalog and use a volume OS environment other than "MSPCP1".
Start S.

The recovery OS of "MSPCP1"
When the OS is booted using the environment 2, specifically, it is realized by making the following settings. However, the recovery OS environment 2 cannot be changed to a normal system.

When the recovery OS 2 is used, parameters are manually selected and the IPL operation is performed.
First, select the system parameters for the one-pack OS. For example, specify “R 00, SYSP = 90, CLPA”. This parameter is a system parameter for the recovery OS, and specifies the volume ID “MSPCP1” of the OS-dedicated environment disk 1.

Next, a catalog is selected. For example, by specifying "R 00,90", the "SY
This means that S1 ”and the recovery OS“ MCAT90 ”have been selected.

Next, the recovery OS "MCAT90" in the OS-dedicated environment disk 1 is restarted.

Further, except for the OS cataloged in the recovery OS environment 4 of FIG. 4, an alternative master catalog is created and cataloged there, and the checkpoint 48 is accessed by selecting the JES startup parameter. A process for switching the destination is performed.

In the above embodiment, the OS for recovery is stored in the normal OS environment disk 1 for the purpose of recovery.
Although the environment is set, an OS such as system generation or maintenance may be set instead of the recovery OS environment instead of the recovery OS environment. In this way, the master catalog on the OS environment disk 1
This is possible by providing a master catalog for other purposes and a master catalog for other purposes.

Further, by incorporating a plurality of environments for the purpose of recovery into a free area in one DASD of the OS, various kinds of recovery are possible. This may be any environment other than the recovery OS SPOOL 47 and the recovery OS PAGE 46 shown in the above embodiment.

The present invention is not limited to the above embodiments, but various modifications and applications are possible within the scope of the claims.

[0034]

As described above, according to the present invention, a recovery triber OS environment coexists in a regular OS disk,
It is possible to perform recovery by a batch job when a business system disk failure that causes a system down occurs, and further shorten the recovery time.

If the number of disks in the system is limited, the OS that is highly important in the work that can be set within the free space of the regular OS disk is set as one environment, and the OS is changed to the regular OS disk. By coexisting, it is not necessary to separately prepare a disk for OS.

[Brief description of drawings]

FIG. 1 is a principle configuration diagram of the present invention.

FIG. 2 is a diagram showing a system disk arrangement according to an embodiment of the present invention.

FIG. 3 is a flow chart showing an operation up to recovery from a failure according to an embodiment of the present invention.

FIG. 4 is a diagram for explaining activation of a recovery OS according to an embodiment of the present invention.

FIG. 5 is a diagram showing a relationship between an OS dedicated volume and an OS environment volume that are normally used.

FIG. 6 is a configuration diagram of a one-pack OS.

FIG. 7: OS in case of disk failure in conventional network
It is a figure for demonstrating the case where it starts.

[Explanation of symbols]

1 OS Dedicated Disk 2 OS Environment Disk 3 Regular OS Master Catalog 4 OS Environment Area, Recovery One Pack OS, Recovery OS Environment 6 Page Data Set 8 Shared System Data Set 10 OS Dedicated Volume 11 OS Environment Volume 20 One Pack OS 21 Checkpoint 22 PAGE 23 SPOOL 24 User management book 25 RACF management book 26 SYS1. STGINDEX 45 Recovery OS Parameter 47 Recovery OS Spool 48 Check Point 49 User Management Book 50 RACF Management Book 51 SYS. STGINDEX 100 General-purpose machine 200 Network 300 Center 500 Field engineer

Claims (2)

[Claims] 1. A system recovery system characterized in that a recovery operating system (hereinafter referred to as OS) environment (4) coexists in a disk (1) of the OS to perform recovery when a failure occurs. 2. The system recovery system according to claim 1, wherein the capacity of the driver OS environment for recovery is set in accordance with the free capacity of the disk of the regular OS.