JPH0426737B2 - - Google Patents

Description

[Detailed Description of the Invention] [Summary] During testing, when an area management module is requested to release an area, the area that was accidentally released is referenced by reversing the bits in that area and releasing it. Make it easier to detect such malfunctions.

[Industrial application field]

The present invention relates to a program testing method in an information processing system, and in particular, when an area once acquired during a program test is returned and released, there is a program that erroneously references the released area. , relates to an area management method for making it easier to detect malfunctions.

[Conventional technology]

Generally, in a program composed of multiple modules, from the standpoint of efficient use of memory resources, each module acquires the area it needs during execution, returns and frees that area when processing is completed, and uses it for other modules. A method is being taken to enable its use. In this case, a GETMAIN macro is issued to acquire an area, a FREEMAIN macro is issued to return an area, and each service is received from the supervisor program.

For example, consider a program with a configuration as shown in FIG. In this program, multiple submodules are controlled under the main control module MAIN.
SUB-1, SUB-2, ..., SUB-n are subordinated. Here, it is assumed that the following area usage is required.

The area acquired by MAIN is referenced by SUB-1 to SUB-n and returned by MAIN.

The area acquired and used by SUB-1 is SUB-
Return it in 1.

The area acquired by SUB-2 is SUB-1~n
Reference it with , and return it with SUB-n.

The area acquired and used by MAIN is returned by MAIN.

Normally, in this case, a GETMAIN macro is issued each time an area is acquired in ~, but
The GETMAIN macro generates an SVC (supervisor call) and switches to supervisor program processing, which increases overhead and degrades performance. For this reason, as shown in FIG. 4, a method is often taken in which a program-specific area management module is provided.

The functions of this area management module are
Issue the GETMAIN macro to acquire a certain size of area from the supervisor program, and when each other module issues the GETMAIN macro, divide and use the area that you acquired with the GETMAIN macro. The available area is notified to the requesting module, and when an area release request (return) is made using the FREEMAIN macro from each module, the area is transferred to the next GETMAIN without actually issuing the FREEMAIN macro.
This is replaced by having the area management module manage this area as a usable area for the macro.

To explain the example of FIG. 3 above using the case of FIG. 4, the above-mentioned requests for acquisition and return of areas are performed by respectively calling the area management module.

In the acquisition request, the GETMAIN macro is issued in a certain unit (such as one page) and a part of it is passed to the requester.

In the acquisition request, a portion of the remaining area acquired in is returned to the request source. Further, in the return request at this time, the area is managed as unused information.

When an acquisition request is made, the area that is managed as unused is returned to the request source. Even when a return request is made at this time, the area is managed as unused.

But it's the same.

In this program, the area actually acquired by the area management module using the GETMAIN macro is returned using the FREEMAIN macro at the end of the program.

This greatly reduces the number of GETMAIN and FREEMAIN operations.

[Problem that the invention seeks to solve]

In a program that has an area management module like the one shown in Figure 4, a certain module accidentally opens an area that should not be opened.
I issued the FREEMAIN macro and released it,
Then, the area is expanded from other modules.
If the area is reused by the GETMAIN macro, for example, if the area is used as a control table, the contents of the control table may be rewritten by another reused module.

Therefore, if the module that released the area by mistake first refers to the control table for that area as if it has not been released, a malfunction will occur if the contents have already been rewritten by another module, so the module that released the area by mistake will An error was discovered in the program that released the .

However, if the control table in the area reused by the other module above is not rewritten, the original module's control table data will be saved as is, so if the original module references the control table, it will not work properly. It appears to be working and does not malfunction.

Furthermore, because it is necessary to optimize the use of the area by the GETMAIN macro, the timing at which the area released by issuing the FREEMAIN macro will be reused will vary. Therefore, at the testing stage
Detecting errors in issuing the FREEMAIN macro becomes more difficult.

Therefore, in the past, the area released by the FREEMAIN macro was sometimes cleared with "FFFF..." or "0000...", but in that case, the original data was replaced with continuous "F" or "0" data. If it is included, it cannot be completely cleared, so there is a possibility that it will not malfunction.

As a result, there was a problem that no errors were discovered during program testing, and the system malfunctioned after it was shipped to the customer.

[Means for solving problems]

In order to solve the above-mentioned conventional problems, the present invention completely destroys the original data by inverting all the bit values in the area to be released by the FREEMAIN macro, thereby preventing the incorrect issuing of the FREEMAIN macro. This ensures that a malfunction will occur if the module subsequently references that area.

FIG. 1 shows the basic configuration of the present invention.

In the figure, 1 to 5 are modules that constitute the test target program, of which 1 is the main control module MAIN, and 2, 3, and 4 are sub modules SUB-1, SUB-2, ..., SUB-, respectively.
n, 5 is an area management module.

6 is an area acquired by the area management module 5 by issuing an area acquisition command (GETMAIN macro).

Reference numeral 7 denotes an area acquisition command corresponding unit that performs processing of cutting out a usable area from the area 6 and allocating it to the module that issued the area acquisition instruction in response to an area acquisition command (GETMAIN macro) issued by another module.

Reference numeral 8 denotes an area release command support unit that performs processing to change the corresponding area returned by an area release command (FREEMAIN macro) issued by another module into a usable area.

9 is a bit inversion function that inverts the value of each bit in the area when the area release command support unit 8 changes the returned area to a usable area, and is activated when the program is in a test environment. It will be done.

[Effect]

In the basic structure of the present invention shown in FIG.
An area of a necessary size is cut out from the unused area in , and the area is allocated and notified to the requesting module SUB-1.

When module SUB-1 finishes processing, it issues an area release command and requests return of the acquired area. Accordingly, the area management module 5
The area release command response unit 8 of
Change the area allocated to SUB-1 to an unused area. At this time, the bit inversion function 9 is used to invert each "0" to a "1" and each "1" to a "0" for all bits in the area changed to an unused area.

In this way, the data in the returned area is completely destroyed, so if a module erroneously issues an area release command and returns the area and then references that area, it will definitely malfunction. ,
You can discover errors in programs.

〔Example〕

FIG. 2 shows an embodiment of the present invention.

In the figure, 15 is an area management module, 16
is the area, 16a is the flag table, and 17 is the area.
GETMAIN compatible part, 18 is FREEMAIN compatible part,
19 is a bit inverting function, 20 is a main control table used for program execution, and 21 is a mode display field for displaying debug mode or normal mode. Note that the components indicated by 15 to 19 in FIG. 2 correspond to the components indicated by 5 to 9 in FIG. 1.

To explain briefly, area management module 15
is area 1 acquired using the GETMAIN macro
6 is divided into a certain size, and the area is managed using a flag table 16a that displays a flag with "0" or "1" to indicate whether each area is unused or in use.

In response to a GETMAIN macro from another module, the GETMAIN support unit 17 searches the flag table 16a for an unused area (an area with a flag of "0") and allocates an area of the necessary size.
Also, the flag corresponding to the allocated area is changed from "0" to "1" to indicate that it is in use (allocated).

The FREEMAIN support unit 18 releases the allocated area in response to the FREEMAIN macro from the module that is using the area. In that case, the corresponding flag in the flag table 16a is changed from "1" to "0", and the bit inversion function 19 is operated in the test mode.

The main control table 20 is provided with a mode display field 21 for indicating the processing mode, normal mode, or debug mode. When executing a program test, a debug mode display is set (for example, debug mode is specified as an option when compiling the source).

The bit reversal function 19 is activated only when the mode display field 21 is displaying the debug mode, and sequentially reads out addresses within the release target area, and combines each read data with "FFF...F" (all
1) and writes the bit-inverted result to the original address. In this way, the values of all bits within the area to be released are inverted and the original values are destroyed.

〔Effect of the invention〕

As described above, according to the present invention, when testing a program having a unique area management module, errors in area returns and references included in the program can be easily discovered, and the reliability of the program can be improved. .

[Brief explanation of drawings]

FIG. 1 is a basic block diagram of the present invention, FIG. 2 is a block diagram of one embodiment of the present invention, and FIGS. 3 and 4 are explanatory diagrams of different conventional area management systems. In Fig. 1, 1...main control module MAIN,
2, 3, 4...Sub module SUB-1, SUB-
2, SUB-n, 5...area management module, 6
...Area, 7...Area acquisition command support section, 8...Area release command support section, 9...Bit inversion function.

Claims (1)

[Claims] 1. In an information processing system that processes a program composed of a plurality of modules including a unique area management module 5, the area management module 5 issues an area acquisition command to acquire an area of a certain size. After acquiring area 6, when another module in the program issues an area acquisition command and makes an area acquisition request, the own module cuts out an unused area in area 6 that was acquired earlier and sends it to the requester. When the area acquisition instruction support unit 7 that allocates the area to a module and makes it usable, and another module in the program issue an area release instruction and request an area return for the area in use, the corresponding allocated area The area release instruction support unit 8 changes the returned allocated area to an unused area during a program test. An area management method for program testing that is characterized by inverting the values of all bits within that area.