JPH09222998A - Module managing device for computer system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To unnecessitate the exchange operation of modules conventionally required for calling the modules in multiplex manner by designatedly calling any arbitrary module only by reloading a valid flag when plural modules having the same name are loaded. SOLUTION: On a module managing table, an area is provided for storing the valid flag showing whether the module is valid or invalid for each management information of each loaded module, and the valid flag in this area is reloaded based on an operation input. At the same time, corresponding to the module request of a system, any module indicating the effective valid flag is selectively called out of the management information of index numbers correspondingly to the module names on the managing table.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to improvement of module management in a computer system in which a resident module can be replaced while the system is operating.

[0002]

2. Description of the Related Art Conventionally, in managing a module in a computer system in which a resident module can be replaced, the resident module may be replaced during system operation for the purpose of improving functions. At this time, the replaced modules are deleted as they are. for that reason,
After that, when it was necessary to call the module before the replacement, the module was replaced again. The situation where you want to call the module before replacement is to measure the processing speed of each module by replacing two or more modules that have the same name but different object code and are started, and use it for tuning work. For example, when you want to compare the behavior of each module by swapping modules of the same name and starting them for debugging.

[0003]

Therefore, the conventional module management has the following problems. (1) After the modules have been replaced, the module before the replacement cannot be specified and called unless the processing at the request source is changed to replace the modules before the replacement and again after the replacement. (2) Furthermore, after an exchange of modules, if an error occurs when the modules before and after the exchange are called multiple times according to the processing of the request source, it is determined that there are two modules with the same name. , It is not possible to identify which module caused the error. (3) After switching the modules, if you try to call the modules before and after the switching according to the processing of the request source, the modules for which an error has already been found at that stage will also be called. , It may interfere with the subsequent processing.

[0004]

In order to solve the above-mentioned problems, the invention of claim 1 stores the location information on the main memory of the loaded module in the module management table during system operation. In the module management device of the computer system that enables the replacement of the resident module, the management information of each module loaded on the module management table is assigned the order of the index number assigned to the module name and the order of the loaded generation. In addition to the binary array, an area for storing the valid flag for displaying the valid / invalid of the module is provided for each management information, and the valid flag on this management table is rewritten based on the operation input and the system Module on management table according to module request Wherein the call by selecting the module that valid flag among the management information of the index number corresponding to the name is displayed as valid. As a result, even when a plurality of modules having the same name are loaded, it is possible to operate the valid flag on the module management table and specify and call an arbitrary module.

Further, according to the invention of claim 2, an area for storing an identification code for identifying a loading order among modules having the same name is provided for each management information on the module management table, and the modules are loaded. At this time, the loading order between the modules having the same name is written in the corresponding identification code area on the management table. Therefore, even when a plurality of modules having the same name are loaded, the modules can be identified by the identification code, and the modules can be easily managed.

Further, according to the invention of claim 3, an area for storing an error mark indicating whether or not an error has occurred is provided for each management information on the module management table, and an error occurs in the module in the execution environment of the module. When it is detected, an error mark is written in the corresponding error mark area on the management table and the corresponding valid flag is rewritten to be invalid. This prevents the module in error from being accidentally called when the module is called from the system.

[0007]

Embodiments of the present invention will be described below. The first embodiment is a table that manages modules in a system in which a resident module can be replaced during system operation (hereinafter referred to as a module management table).
By providing the main memory location information about the pre-replacement module and the post-replacement module and a valid flag indicating which module is currently valid, and providing a means for changing the flag at any timing, Accordingly, it is possible to call the pre-replacement module and the post-replacement module multiple times. For that purpose, for each module in the module management table having the same module name, a location information on each main memory and a valid flag storage area indicating the validity of calling are provided.

As a result, when the modules are replaced, the module information in the module management table is moved to the module information of the older generation, the latest module is loaded, and the information of the module is set as the latest module information. At this time, the valid flag is set in the entry of the latest module, and the valid flags set in other entries are canceled. When calling a module, first, a module with a valid flag is searched from an index number obtained by searching the module name, and a module with a valid flag is called. Since the valid flag can be set directly, it can also be called by setting the valid flag in the module before replacement if necessary. However, at this time, the valid flag is set to only one of the module groups having the same module name. As a result, after the modules are replaced, the modules before and after the replacement can be arbitrarily specified and called without changing the processing of the request source and without replacement. .

Further, in addition to the configuration of the first embodiment, the second embodiment has an identification code for distinguishing a module group having the same module name for each entry in the module management table, and when a module is called, By providing a means to call the index number and identification code of the module management table and place them in the execution environment of the module, the module before replacement and the module after replacement may be called multiple times. If you do, you can see in which module the error occurred. For that purpose, an identification code for distinguishing each module is provided for the modules in the module management table having the same module name.

Further, when calling a module, an index number (location determined by the module name) and an identification code in the module management table are set in the environment associated with the calling module. It should be noted that this information can be referred to by the error detection unit.
As a result, the error detection unit can know the index number and identification code of the module in which the error has occurred from the execution environment of the module that is currently operating. As a result, if an error occurs after the modules are swapped and the modules before and after the swap are called multiple times according to the processing of the request source, which module among the modules with the same name Can identify if an error occurred.

In the third embodiment, the means for changing the setting of the valid flag from the module in which an error has occurred to the module in which no error has occurred is utilized by utilizing the error module identification means of the second embodiment. In preparation, the module in which an error has occurred is not automatically called even when there are a plurality of replacement modules. Therefore, for the modules in the module management table having the same module name, an error mark storage area indicating that an error has occurred is provided, and when the error occurrence module is specified by the second embodiment,
Set an error mark in the error mark storage area of the corresponding module.

At this stage, if the valid flag is set for the error-occurring module, the valid flag is released, and the module having no error mark is searched from the modules having the same index number. If it exists, the valid flag is set to that module and the valid flag of the error occurrence module is cleared. As a result, the module is called based on the valid flag, so if the module name of the module in which an error occurred after this processing is called,
Since the module in which no error has occurred is called, there is no need to replace the module again, and the processing of that module does not have to be interrupted. As a result, it is known that an error has occurred at that stage when the modules before and after replacement are to be called according to the processing of the request source after the modules have been replaced. Will never be called.

Next, a specific structure of each embodiment will be described with reference to the drawings. FIG. 1 is a block diagram showing the main components of the module management device according to the embodiment. As shown in the figure, the module management device includes a module management table 1 that manages information about modules of the same name for two generations, a module calling unit 2 that performs processing when calling a module, and a module replacement unit 3 that performs processing for module replacement. , Module management table 1
Valid flag operating unit 4 for operating the valid flag inside, error processing unit 5 for identifying and processing the error source module when an error occurs in the module, storing the execution environment when each module operates And a module execution environment area 6 for executing.

FIG. 2 is an explanatory diagram showing the internal structure of the module management table 1. This table has a two-dimensional structure as shown in the drawing, and has a vertical entry that can be identified by the module name and a horizontal entry that indicates the generation of the module with the same module name. FIG.
5 is an explanatory diagram showing entry contents for module information corresponding to unit modules in the module management table 1. FIG. In this, an area 11 for storing a valid flag for determining a calling module, an area 12 for storing an error mark indicating whether or not an error has occurred in the module, an area 13 for storing module location information such as an entry address of the module, a module An area 14 is provided for storing a module identification code indicating the loading generation of.

Next, the processing operation of the module management device will be described with reference to the flowchart. FIG. 4 is a flowchart showing the processing when the modules are replaced.
When replacing the modules, first, the index number of the module name N-1 in the module management table 1 is acquired (step 401). The generation (S) that is one older than the latest generation in the entry of the index number acquired next
-2) It is checked whether the module location information in the module information is valid (step 402), and if it is valid, the module is deleted (step 403). Here, if the module location information is invalid, S-2
The module is assumed not to exist. Then, the latest generation (S-1) module information is copied to the S-2 module information area (step 404).

Then, it is checked whether or not the valid flag of the S-2 module information is ON (step 40).
5) If it is ON, turn it OFF and release it (step 406). This is so that the replaced module is called. Next, the replacement module, that is, the latest module is loaded (step 407), and then the information of that module is newly added to the S-
It is set as one module information (step 408).
At the same time, the identification code set in the S-1 module information until then is set to +1 as the identification code (step 409). Similarly, the error mark area is set to the non-setting state, and the valid flag is set to ON (step 410).

FIG. 5 is a flow chart showing the processing when a module is called. When calling a module, first, the index number of the module name N-1 in the module management table 1 is acquired (step 50).
1). Next, it is checked whether the module location information in the module information of the latest generation (S-1) in the entry of the acquired index number is valid (step 502),
If it is valid, the valid flag is continuously checked (step 50).
3). If the valid flag is set, the index number and the identification code in the module table are set in the execution environment of the module based on the location information of the module (step 504) and the module is called (step 505).

When the module location information is not valid (NO in step 502) and when the valid flag is not set in the SI module information (NO in step 503), the location information and valid flag of the S-2 module information are set. Examine (step 506,
507). Here, if the location information itself of the S-2 module information is invalid, that is, the S-2 module does not exist (NO in step 506), and if the valid flag is not set in the S-2 module information (NO in step 507), A call error occurs (step 510).

FIG. 6 is a flow chart showing the processing when an error occurs in the module. When an error occurs in a module, first, the index number (1) and the identification code of the module management table 1 are acquired from the execution environment of the module in which the error occurred (step 60).
1). It is checked whether or not there is module information that can be identified by the acquired index number and identification code (step 602), and if there is, an error mark is set in that module information (step 603). At the same time, it is checked whether or not the valid flag of the module information is set to ON (step 604).

If the valid flag is set to ON, it is checked whether or not there is module information in which an error mark is not set for a module having another identification code with the same index number (step 605). In this case, the valid flag of the module information is set to ON (step 606), and the valid flag of the module information of the error occurrence module is set to OFF and released (step 607). After that, standard error processing such as recording error information and notification of error occurrence is performed (step 60).
8).

Next, the processing for changing the valid flag of the module will be described. First, the index number of the module name N-1 in the module management table 1 is acquired. Next, the valid flag in the module information corresponding to the specified identification code in the entry of the acquired index number is set to ON. Next, similarly, the valid flag in the module information corresponding to the identification code for which cancellation is designated is turned off and the cancellation is performed. As a result, subsequently, when the module is designated and called, the module for which the valid flag is newly set is called. In this way, by changing the valid flag, it is possible to specify and call a specific module of the same name modules.

In the above-described embodiment, the following effects can be obtained. (1) After replacing the resident module while the system is operating, in the situation where you want to call the pre-replacement module for the purpose of improving the function or tuning of that module, you do not have to spend the overhead of replacing the module again, and It becomes possible to call it at high speed just by changing the setting of the valid flag for the module. (2) By setting the identification code of the calling module in the execution environment of the module, even if the module before and after the replacement is called multiple times or an error occurs in either module, it is accurate Since it is possible to identify in which case the error occurred, it is possible to take an appropriate response.

(3) By automatically setting the error mark and the valid flag in the module management table using the error module specifying means,
As for the module called after that, the module in which no error has occurred is called. Therefore, when an error occurs in the related art, it is possible to continue the process that was normally interrupted until the module is replaced, without interrupting the process. In the above-described embodiment, the number of generations in the module management table is set to 2
However, it is possible to set the number of generations to three or more. In that case, the number of generations in the horizontal direction (generation number entry) of the module management table is increased, and the other configurations can be realized. In this case, more module generations can be managed.

[0024]

As described above, according to the first aspect,
When multiple modules with the same name are loaded by providing a valid flag on the management table,
Only by rewriting the valid flag, it becomes possible to specify and call an arbitrary module in the module, and the module replacing operation which is conventionally required when multiple modules are called is unnecessary.

Further, according to the second invention, by providing an area for storing the identification code on the management table and writing the loading order in the identification code area when a plurality of modules having the same name are loaded. Modules having the same name can be distinguished from each other, which facilitates module management.

Further, according to the third invention, an area for storing an error mark is provided on the management table, and when an error occurs in the module, the error mark is written in the corresponding area, so that the module in which the error occurred can be identified. You can prevent accidental calling.

[Brief description of drawings]

FIG. 1 is a block diagram showing a module management device according to an embodiment of the present invention.

FIG. 2 is an explanatory diagram showing an internal configuration of a module management table of FIG.

FIG. 3 is an explanatory diagram showing a region configuration of the module information of FIG.

FIG. 4 is a flowchart showing a processing operation according to the embodiment of the present invention.

FIG. 5 is a flowchart showing a processing operation according to the embodiment of the present invention.

FIG. 6 is a flowchart showing a processing operation according to the embodiment of the present invention.

[Explanation of symbols]

 1 module management table 2 module calling unit 3 module replacement unit 4 valid flag operation unit 5 error processing unit 6 module execution environment area 11 valid flag storage area 12 error mark storage area 13 module location information storage area 14 module identification code storage area

Claims (3)

[Claims] 1. A module management device for a computer system, which enables replacement of a resident module during system operation by storing location information on the main memory of loaded modules in a module management table. A module management table in which the management information of each module is binary-arranged in the order of the index number assigned to the module name and the order of the loaded generations, and a module management table provided for each management information on this management table An area for storing the valid flag for displaying valid / invalid, a means for rewriting the valid flag on the management table based on the operation input, and an index number corresponding to the module name on the management table in response to a system module request. Effective flag in management information Module management system of the computer system, characterized in that is provided with a means for calling by selecting a module which is effective display. 2. A module management device for a computer system according to claim 1, wherein an area provided for each management information on a module management table and storing an identification code for identifying a loading order between modules having the same name. A module management device for a computer system, comprising: a module for loading a module in the corresponding identification code area on the management table when the modules are loaded; 3. The module management device for a computer system according to claim 1, wherein an area is provided for each management information on the module management table and stores an error mark indicating whether or not an error has occurred, and the module. When an error is detected in the module in the execution environment of, the error mark is written in the corresponding error mark area on the management table and the corresponding valid flag is rewritten to invalid. A computer system module management device.