JP2023057721A - Verification program, verification method, and information processing device - Google Patents

Abstract

To enable an occurrence spot of an incompatible operation to be easily located.SOLUTION: An information processing device 10 executes a first execution program 2 for execution of processing according to a verification object program 1 in a first program execution environment 12a to thereby acquire a first data change history 6 having a change content of a value of first data 4 with a first data change instruction recorded therein. The information processing device 10 executes a second execution program 3 for execution of the processing according to the verification object program 1 in a second program execution environment 12b to thereby acquire a second data change history 7 having a change content of a value of second data 5 with a second data change instruction recorded therein. The information processing device 10 detects an incompatible operation by comparing the first data change history 6 with the second data change history 7.SELECTED DRAWING: Figure 1

Description

The present invention relates to a verification program, verification method, and information processing apparatus.

Some application software (hereinafter simply referred to as "applications") used in business were developed long ago and are still in operation today. In particular, applications written in the COBOL language have many such cases.

On the other hand, the execution environment (hardware, OS (Operating System), character code system, etc.) for executing applications changes with the times. Therefore, in order to continue to operate the same application over a long period of time, work is performed to migrate the application to a new execution environment in accordance with changes in the execution environment.

When migrating an application to a new execution environment, it is desirable to be able to migrate by simply switching the execution environment without making major modifications to the application. However, the data format of data handled in the execution environment before and after migration (bit width of CPU (Central Processing Unit), endian, floating point format, character code, etc.) may differ. In this case, even if there is no change in the processing logic of the application program, unintended behavior (incompatible behavior) may occur during application execution due to differences in data formats. Therefore, when changing the execution environment of an application, the operator must verify the operation in the migration destination environment.

Various techniques have been proposed for automating verification work associated with migration of an application execution environment. For example, in a system migration test, when analyzing the difference between the current system and the new system, the part where the application has been modified is excluded from the analysis target, and the migration test support system makes it easier to analyze the cause of the difference between the old and new systems. is proposed.

Japanese Unexamined Patent Application Publication No. 2012-203580

However, with the conventional technology, it is difficult to identify in advance the cause of an incompatible operation that occurs due to the difference in the data format of the execution environment before and after migration. For example, the operator performs test execution of the application in the migration destination environment, performs code review and debugging with a debugger when incompatible behavior occurs, and traces the logic from the incompatible behavior portion to identify the cause. This method requires a lot of man-hours because the location of the cause is identified manually. Also, if there is an incompatible behavior that occurs in a situation not covered by the test, such incompatible behavior cannot be detected. If this incompatible behavior becomes apparent after the application starts operating at the migration destination, it may cause a failure in the actual operating environment.

In one aspect, this application aims to make it possible to easily identify the location of occurrence of incompatible behavior.

In one proposal, a verification program is provided that causes a computer to perform the following processes.
The computer causes a first execution program for executing, in a first program execution environment, a process according to the verification target program including the verification target instruction that changes the value of the data, based on the verification target instruction. A first recording command is added to record the content of change made by the first data change command set in the program. The computer executes the first execution program in the first program execution environment, thereby obtaining a first data change history in which changes to the value of the first data according to the first data change instruction are recorded. . The computer changes the second data set in the second execution program based on the verification target instruction to the second execution program for executing the process according to the verification target program in the second program execution environment. Add a second recording instruction that causes the changes made by the instruction to be recorded. The computer executes the second execution program in the second program execution environment to obtain a second data change history in which changes to the value of the second data according to the second data change instruction are recorded. . The computer then detects the incompatible operation by comparing the first data change history and the second data change history.

According to one aspect, it is possible to easily identify the location where the incompatible operation occurs.

It is a figure which shows an example of the verification method which concerns on 1st Embodiment. It is a figure which shows an example of the system configuration|structure of 2nd Embodiment. It is a figure which shows an example of the hardware of a development machine. FIG. 2 is a diagram showing an example of functions that the behavior development system has for verifying the behavior of an application; FIG. 10 is a diagram showing an example of an executable file generation situation; FIG. 10 is a diagram illustrating an example of a compilation processing procedure; FIG. 10 is a diagram showing an example of compilation; It is a figure which shows an example of generation|occurrence|production of a data change log|history, and a comparison process. It is a figure which shows an example of a data change log. 9 is a flow chart showing an example of the procedure of data change history comparison processing; FIG. 10 is a diagram showing a first example of data comparison processing; FIG. 11 illustrates a second example of data comparison processing;

Hereinafter, this embodiment will be described with reference to the drawings. It should be noted that each embodiment can be implemented by combining a plurality of embodiments within a consistent range.
[First Embodiment]
First, the first embodiment will be explained. The first embodiment is a verification method that makes it possible to easily identify a location where an incompatible operation due to a difference in data format occurs when migrating a program execution environment.

FIG. 1 is a diagram showing an example of a verification method according to the first embodiment. FIG. 1 shows an example of an information processing device 10 that implements the verification method. The information processing device 10 can implement the verification method by executing the verification program.

The information processing device 10 has a storage unit 11 and a processing unit 12 in order to implement the verification method. The storage unit 11 is, for example, a memory or a storage device that the information processing device 10 has. The processing unit 12 is, for example, a processor or an arithmetic circuit included in the information processing device 10 .

The storage unit 11 stores the verification target program 1 . The verification target program 1 is, for example, a source program written in a high-level language. The verification target program 1 includes verification target instructions that change data values.

The processing unit 12 has a first program execution environment 12a and a second program execution environment 12b. The processing unit 12 has, for example, a compiler that compiles the verification target program 1 for the first program execution environment 12a and a compiler that compiles it for the second program execution environment 12b.

The first program execution environment 12a and the second program execution environment 12b are program execution environments including hardware and OS. The first program execution environment 12a and the second program execution environment 12b can be implemented using virtual machines, for example. Also, if the information processing apparatus 10 is a computer system including a plurality of computers, the first program execution environment 12a and the second program execution environment 12b may be implemented on different computers. The first program execution environment 12a and the second program execution environment 12b mainly differ in the data format of data handled (CPU bit width, endian, floating point format, character code, etc.).

Here, the user of the information processing apparatus 10 uses the execution program generated based on the verification target program 1 to transfer the service operated on the first program execution environment 12a to the second program execution environment 12b. It is assumed that In this case, the user verifies whether the program to be verified 1 compiled for the second program execution environment 12b operates normally. In the operation verification, the operator causes the processing unit 12 to execute the following processes.

The processing unit 12, for example, compiles the verification target program 1 in the first program execution environment 12a, thereby performing a first execution process for executing the process described in the verification target program 1 in the first program execution environment 12a. Generate program 2. At this time, the processing unit 12 issues to the first execution program 2 a first recording instruction that causes the first execution program 2 to record the changed content by the first data change instruction set in the first execution program 2 based on the verification target instruction. to add. Further, the processing unit 12 causes the first execution program 2 to be executed in the first program execution environment 12a, thereby creating a first Acquire the data change history 6.

Further, the processing unit 12 compiles the verification target program 1 in the second program execution environment 12b, for example, so that the processing described in the verification target program 1 is executed in the second program execution environment 12b. Generate execution program 3. At this time, the processing unit 12 issues a second recording instruction to the second execution program 3 to record the changed contents by the second data change instruction set in the second execution program 3 based on the verification target instruction. to add. Furthermore, the processing unit 12 causes the second execution program 3 to be executed in the second program execution environment 12b, thereby creating a second data 5 in which changes to the value of the second data 5 according to the second data change instruction are recorded. Acquire the data change history 7.

The second data 5 is data to which a value having the same meaning as the first data 4 is set, for example, if there is no incompatible operation. For example, if the first data 4 is a character string, the second data 5 is also set to a value indicating the same character string. However, the data format of the second data 5 may differ from the data format of the first data 4 . For example, the character code system representing the character string of the first data 4 and the character code system representing the character string of the second data 5 are different. In this case, the value (character code) of the first data 4 and the value (character code) of the second data are different, but the meaning (character string) represented by each character code is the same.

After acquiring the first data change history 6 and the second data change history 7, the processing unit 12 compares the first data change history 6 and the second data change history 7 to determine the data format. Detect incompatible behavior due to differences. For example, the processing unit 12 acquires the first data change history 6 including the values before or after the change of the first data 4 . The processing unit 12 also acquires the second data change history 7 including the values before or after the change of the second data 5 . The processing unit 12 is represented by the meaning represented by the value of the first data 4 shown in the first data change history 6 and the value of the second data 5 shown in the second data change history 7. It is determined that there is an incompatible behavior if different meanings are expressed. In other words, if the first data modification instruction and the second data modification instruction are instructions set based on the same verification target instruction, the data modification operation to a value that expresses a different meaning is performed. (incompatible operation).

For example, it is assumed that the first data change instruction of the first execution program 2 intends to change the value of data in the standard data format in the first program execution environment 12a. In this case, based on the first data change command, the first data 4 is interpreted as data in the standard data format in the first program execution environment 12a, and the change processing is performed.

Similarly, assume that the second data modification instruction of the second executable program 3 is intended to modify the value of data in the standard data format in the second program execution environment 12b. In this case, based on the second data change instruction, the second data 5 is interpreted as data in the standard data format in the second program execution environment 12b, and the change processing is performed.

At this time, if the data format of the second data 5 is different from the assumed data format, the meaning represented by the value of the second data 5 after change is different from that of the first data 4 after change. It has a different meaning from the meaning represented by the value of . As a result, it is determined that there is an incompatible operation (change of data to a value representing a different meaning).

When detecting an incompatible operation based on a difference in data format, for example, the processing unit 12 determines the first data format required for the first data 4 and the value before or after the change of the first data 4. and the first data change history 6 is acquired. The processing unit 12 also acquires the second data change history 7 including the second data format required for the second data 5 and the values before or after the change of the second data 5 . Furthermore, the processing unit 12 converts the first data 4 and the second data format based on the first data format indicated in the first data change history 6 and the second data format indicated in the second data change history 7 converts at least one of the data formats of the data 5 of The processing unit 12 then compares the values of the first data 4 and the second data 5 .

In the example of FIG. 1, the first data change history 6 indicates that the data value is "A4A2A4A4A4A68140" and that the data format is "Japanese EUC (Extended UNIX (registered trademark) Code) character string". It is shown. The second data change history 7 indicates that the data value is "A4A2A4A4A4A68140" and the data format is "UTF (Unicode Transformation Format)-16LE (Little Endian) character string". . In the example of FIG. 1, the data values shown in the first data change history 6 and the second data change history 7 are the same. However, the character code system interpreted when the first execution program 2 is executed differs from the character code system interpreted when the second execution program 3 is executed. This can occur in the second program execution environment 12b also when Japanese EUC data is input as a processing object of the second execution program 3. FIG.

In this case, the processing unit 12 unifies the character codes of the first data 4 and the second data 5 and compares the values of the first data 4 and the second data 5 . For example, the processing unit 12 converts the value of the first data 4 (character code of Japanese EUC) to the character code of UTF-16LE, and converts the value after conversion of the first data 4 and the second data 5 Compare with value. Then the values will not match. That is, the meanings (character strings) represented by the data values shown in the first data change history 6 and the second data change history 7 are different. In this case, the processing unit 12 determines that an incompatible operation occurs in the part of the verification target instruction of the verification target program 1 .

In this manner, the information processing apparatus 10 can easily identify the cause of the incompatible operation. Moreover, it is possible to detect incompatible operations caused by differences in data format with high accuracy.
For example, when the character code system of the second data 5 is different from the character code system assumed in the second data change instruction, the value that does not exist in the character code system assumed for the character code of the second data 5 If so, it is conventionally easy to detect the fraud of the second data 5 . However, in general, if the character code set as the value of the second data 5 is a character code that also exists in the character code system assumed in the second data change instruction, it is treated as an error. It is difficult to detect. In many cases, processing continues without being detected as an error, and the problem manifests itself as garbled characters.

On the other hand, the processing unit 12 detects incompatible operations by comparing the first data change history 6 and the second data change history 7 . As a result, even if the character code of the second data 5 is also present in the character code system assumed in the second data change instruction, the character code system of the second data 5 is assumed. If it is different from what it is, it can be detected as incompatible behavior. Therefore, it is possible to accurately detect an incompatible operation caused by a difference in data format.

If an incompatible operation occurs due to a difference in data format, the user should, for example, review the processing logic up to the verification target instruction, which is the cause of the problem, and verify that even if data with a different data format than expected is input, it can be processed correctly. Correct the target program 1. Alternatively, the user can check the data read by the verification target instruction and set the environment in the second program execution environment 12b so that the data format of the input data is as expected. .

In addition, the processing unit 12 may compare the data names of the first data 4 and the second data 5 to confirm that data having the same data name are to be compared. In that case, the processing unit 12 acquires the first data change history 6 including the first data name that identifies the first data 4 . The processing unit 12 also acquires the second data change history 7 including the second data name that identifies the second data 5 . The processing unit 12 then compares the first data name indicated in the first data change history 6 and the second data name indicated in the second data change history 7 and confirms that they match. If the processing logic of the first execution program 2 and the second execution program 3 are the same, the data name of the first data 4 whose value is changed by the first data change instruction and the value is changed by the second data change instruction. The data name is the same as the data name of the second data 5 to be changed. Therefore, when the data name of the first data and the second data name do not match, it can be determined that the processing logics are different (the two execution programs are not equivalent programs). That is, it can be confirmed that the processing logic is not changed when the processing by the first execution program 2 executed in the first program execution environment 12a is transferred to the second program execution environment 12b.

In addition to the character code, the data format includes endian, floating point representation, and the like. Note that if the first data 4 and the second data 5 have different floating-point representation formats, the processing unit 12 can unify the data format of either one of the data to increase the precision of the numerical values represented by the floating-point. It may deteriorate. Therefore, when the first data 4 and the second data 5 have different floating-point representation formats, the processing unit 12 converts the first data 4 and the second data 5 into the third representation format. good too. For example, the processing unit 12 may convert the first data 4 and the second data 5 into numerical values (arrangements of numerals and decimal points) indicated by the values of these data. Thereby, the meaning (numerical value) represented by the value (floating point) of the first data 4 and the second data 5 can be correctly compared.

[Second embodiment]
Next, a second embodiment will be described. In the second embodiment, when an application running on a computer with a certain execution environment is migrated to a computer with a different execution environment, operation verification is performed in advance in the development environment, and incompatible operations due to differences in data formats are verified. It confirms the presence or absence of

FIG. 2 is a diagram showing an example of a system configuration according to the second embodiment. FIG. 2 shows a system configuration example in which the development system 100 is used to verify the operation of an application in advance when migrating the execution environment of the application being executed in the operation system 200 .

For example, a development system 100 and an operation system 200 are connected via a network 20 . The development system 100 includes two development machines 100a and 100b used by application developers. The operating system 200 includes two operating machines 200a and 200b that are used to provide services using applications.

The development machines 100a and 100b are computers prepared for application development and testing. The operation machines 200a and 200b are computers prepared for executing processes using applications and operating various services.

Assume that an application that has been operated on the operating machine 200a is migrated to the operating machine 200b. The operating machine 200b has an operating environment different from that of the operating machine 200a. In this case, in the development system 100, the development machine 100a has the same operating environment as the migration source operation machine 200a, and the development machine 100b has the same operating environment as the migration destination operation machine 200b.

The development machines 100a and 100b may be virtual machines that reproduce the operating environments of the operation machines 200a and 200b, respectively. If both development machines 100a and 100b are virtual machines, both development machines 100a and 100b can be constructed within the same computer.

FIG. 3 is a diagram illustrating an example of hardware of a development machine. The development machine 100 a is entirely controlled by a processor 101 . A memory 102 and a plurality of peripheral devices are connected to the processor 101 via a bus 109 . Processor 101 may be a multiprocessor. The processor 101 is, for example, a CPU, MPU (Micro Processing Unit), or DSP (Digital Signal Processor). At least part of the functions realized by the processor 101 executing the program may be realized by an electronic circuit such as an ASIC (Application Specific Integrated Circuit) or a PLD (Programmable Logic Device).

The memory 102 is used as the main storage device of the development machine 100a. The memory 102 temporarily stores at least part of an OS program and application programs to be executed by the processor 101 . In addition, the memory 102 stores various data used for processing by the processor 101 . As the memory 102, for example, a volatile semiconductor memory device such as a RAM (Random Access Memory) is used.

Peripheral devices connected to the bus 109 include a storage device 103 , a GPU (Graphics Processing Unit) 104 , an input interface 105 , an optical drive device 106 , a device connection interface 107 and a network interface 108 .

The storage device 103 electrically or magnetically writes data to and reads data from a built-in recording medium. The storage device 103 is used as an auxiliary storage device for the development machine 100a. The storage device 103 stores an OS program, application programs, and various data. As the storage device 103, for example, an HDD (Hard Disk Drive) or an SSD (Solid State Drive) can be used.

The GPU 104 is an arithmetic unit that performs image processing, and is also called a graphic controller. A monitor 21 is connected to the GPU 104 . The GPU 104 displays an image on the screen of the monitor 21 according to instructions from the processor 101 . Examples of the monitor 21 include a display device using an organic EL (Electro Luminescence), a liquid crystal display device, and the like.

A keyboard 22 and a mouse 23 are connected to the input interface 105 . The input interface 105 transmits signals sent from the keyboard 22 and mouse 23 to the processor 101 . Note that the mouse 23 is an example of a pointing device, and other pointing devices can also be used. Other pointing devices include touch panels, tablets, touchpads, trackballs, and the like.

The optical drive device 106 reads data recorded on the optical disc 24 or writes data on the optical disc 24 using laser light or the like. The optical disc 24 is a portable recording medium on which data is recorded so as to be readable by light reflection. The optical disc 24 includes DVD (Digital Versatile Disc), DVD-RAM, CD-ROM (Compact Disc Read Only Memory), CD-R (Recordable)/RW (ReWritable), and the like.

The device connection interface 107 is a communication interface for connecting peripheral devices to the development machine 100a. For example, the device connection interface 107 can be connected to the memory device 25 and the memory reader/writer 26 . The memory device 25 is a recording medium equipped with a communication function with the device connection interface 107 . The memory reader/writer 26 is a device that writes data to the memory card 27 or reads data from the memory card 27 . The memory card 27 is a card-type recording medium.

Network interface 108 is connected to network 20 . Network interface 108 transmits and receives data to and from other computers or communication devices via network 20 . The network interface 108 is a wired communication interface that is connected by a cable to a wired communication device such as a switch or router. Also, the network interface 108 may be a wireless communication interface that communicates with a wireless communication device such as a base station or an access point via radio waves.

The development machine 100a can be realized by the above hardware. The other development machine 100b and the operation machines 200a and 200b can also be realized with hardware similar to the development machine 100a. The information processing apparatus 10 shown in the first embodiment can also be realized by hardware similar to the development machine 100a shown in FIG.

The development machine 100a implements the processing functions of the second embodiment, for example, by executing a program recorded on a computer-readable recording medium. A program describing the processing contents to be executed by the development machine 100a can be recorded in various recording media. For example, a program to be executed by the development machine 100 a can be stored in the storage device 103 . The processor 101 loads at least part of the program in the storage device 103 into the memory 102 and executes the program. The program to be executed by the development machine 100a can also be recorded in a portable recording medium such as the optical disk 24, memory device 25, memory card 27, or the like. A program stored in a portable recording medium can be executed after being installed in the storage device 103 under the control of the processor 101, for example. Alternatively, the processor 101 can read and execute the program directly from the portable recording medium.

For example, when an operator who executes an application on the operation machine 200a and provides a service moves the application to another operation machine 200b, for example, the development machines 100a and 100b are used in advance to check the compatibility of the execution environment of the application. Validate. In compatibility verification, it is verified whether or not an unintended operation (incompatible operation) is executed due to a difference in data format.

Examples of incompatible operations due to differences in data formats include the following operations.
The first example is incompatible behavior due to endian differences. Endianness is the type of order in which multiple bytes are arranged. Endian types include big endian and little endian. In big-endian, byte-wise data is ordered from the most significant byte. In little-endian, byte-wise data is ordered from the least significant byte.

A program execution environment that assumes big-endian data input may shift to a program execution environment that assumes little-endian data input. For example, in the program execution environment of the migration source, it is assumed that a 4-byte byte string in network byte order (big endian) is read from the network and processed as it is as a binary integer. At this time, the program execution environment of the transfer destination may handle the acquired data as little endian. In this case, since the endian is different, if the big endian data is executed as it is, the processing is executed as an integer value different from the original value, and an unintended result is output.

A second example is an incompatible operation caused by a difference in character codes. For example, there is a case where the OS for executing a program is shifted from an OS whose system character code is EUC to an OS whose system character code is UTF-16. In this case, the processing logic of the destination computer assumes EUC, so if the acquired character data is input as it is in UTF-16, an unintended result will be output.

In addition, differences in floating-point representation formats can also cause incompatible behavior. In this way, incompatible operations occur due to the difference in data format handled in the program execution environment. Therefore, the operator performs operation verification accompanying execution environment migration using the development system 100, detects incompatible operations caused by the difference in data format, and identifies the cause of the incompatible operations.

FIG. 4 is a diagram showing an example of functions that the behavior development system has for verifying the behavior of an application. The development machine 100 a has a storage unit 110 , a compiler 120 and an execution unit 130 .

The storage unit 110 has a source file 111, an execution file 112, a plurality of data files 113a, 113b, . The source file 111 is a program file in which the contents of application processing are described in a high-level language. The executable file 112 is an executable machine language program file generated based on the source file 111 . Data files 113a, 113b, . The runtime library 114 is a file in which runtimes (software components) that can be used when executing the executable file 112 are registered. The data change history 115 is a log file that stores the data change history when the execution file 112 executes the application.

The compiler 120 translates (compiles) the source file 111 into machine language. That is, the compiler 120 interprets the program described in the source file 111 and generates the execution file 112 that conforms to the program execution environment of the development machine 100a. Since the program execution environment of the development machine 100a is the same as that of the migration source operation machine 200a in the operation system 200, the generated execution file 112 is also compatible with the migration source operation machine 200a. When the compiler 120 detects an instruction that involves changing data in the data area, the compiler 120 adds to the executable file 112 an instruction that records the value of the data before and after the change.

Execution unit 130 is a process that executes executable file 112 . When there is an instruction to read data to be processed in the process of executing the execution file 112, the execution unit 130 reads corresponding data from the data files 113a, 113b, . . . , for example. Also, when the runtime is called during execution of the executable file 112, the execution unit 130 acquires the corresponding runtime from the runtime library 114 and executes the acquired runtime. For example, if a runtime for recording designated data in the data change history 115 is prepared, the execution unit 130 calls and executes the runtime when executing an instruction for recording data values. By executing the execution file 112 by the execution unit 130 , the data change history 115 stores the values before and after the data changed in the process of executing the execution file 112 .

The development machine 100 b has a storage unit 140 , a compiler 150 , an execution unit 160 and a data history comparison unit 170 .
The storage unit 140 has a source file 141, an execution file 142, a plurality of data files 143a, 143b, . A source file 141 is a program file having the same content as the source file 111 . The executable file 142 is an executable program generated based on the source file 141 . The data files 143a, 143b, . . . are files in which data used when executing the execution file 142 are set. The runtime library 144 is a file in which runtimes that can be used when executing the executable file 142 are registered. The data change history 145 is a log file that stores the data change history when the execution file 142 executes the application.

The data files 143a, 143b, . generated by Here, when there are a large number of data files 143a, 143b, . Such omission of data format conversion causes incompatible operations.

Compiler 150 performs compilation of source files 141 into machine language. That is, the compiler 150 interprets the program written in the source file 141 and generates the execution file 142 that conforms to the program execution environment of the development machine 100b. Since the program execution environment of the development machine 100b is the same as that of the migration destination operation machine 200b in the operation system 200, the generated execution file 142 is also suitable for the migration destination operation machine 200b. When the compiler 150 detects an instruction that changes data in the data area, the compiler 150 adds to the executable file 142 an instruction that records the value of the data before and after the change.

Execution unit 160 is a process that executes executable file 142 . When there is a data read instruction to be processed during the process of executing the execution file 142, the execution unit 160 reads the corresponding data from the data files 143a, 143b, . . . , for example. Also, when the runtime is called during execution of the executable file 142, the execution unit 160 acquires the corresponding runtime from the runtime library 144 and executes the acquired runtime. For example, if a runtime for recording designated data in the data change history 145 is prepared, the execution unit 160 calls and executes the runtime when executing an instruction for recording data values. By executing the execution file 142 by the execution unit 160 , the data change history 145 stores the values before and after the data changed in the process of executing the execution file 142 .

The data history comparison unit 170 compares the meanings represented by the values of the data change histories 115 and 145 of both development machines 100a and 100b to detect incompatible operations.
The process of detecting an incompatible operation and identifying the cause of the incompatible operation by the development system 100 is performed in the following procedure.

First, the compilers 120, 150 corresponding to the description language of the programs described in the source files 111, 141 are programmed to automatically record the change history of all data when the programs shown in the execution files 112, 142 are executed. to generate

FIG. 5 is a diagram illustrating an example of how an executable file is generated. For example, in the development machine 100a, the compiler 120 compiles the source file 111 and generates the execution file 112. FIG. Also, in the development machine 100b, the compiler 150 compiles the source file 141 (a copy of the source file 111) to generate the executable file 142. FIG. When compiling the source files 111 and 141, the compilers 120 and 150 add data recording instructions before and after the instruction when detecting an instruction that changes data.

FIG. 6 is a diagram illustrating an example of a compilation processing procedure. The processing shown in FIG. 6 will be described below along with the step numbers, taking as an example the case where the compiler 120 in the development machine 100a compiles.

[Step S101] The compiler 120 selects the statements of the source file 111 one by one from the top, and interprets the processing to be executed according to the selected statements.
[Step S102] The compiler 120 determines whether data will be changed by processing according to the interpreted statement. For example, the compiler 120 determines that data is changed if the instruction involves reading data into the data area of the memory 102 . Compiler 120 advances the process to step S104 if there is a data change. If there is no data change, the compiler 120 advances the process to step S103.

[Step S<b>103 ] The compiler 120 adds a machine language instruction corresponding to the interpreted statement to the execution file 112 . After that, the compiler 120 advances the process to step S107.

[Step S<b>104 ] The compiler 120 adds to the execution file 112 a machine-language instruction for recording the pre-change value of the data to be changed in the data change history 115 . At this time, the compiler 120 records, for example, the address of the data, the name of the data corresponding to the address, the data format, etc., in addition to the value of the data to be recorded before the change.

For example, in a high-level language such as COBOL, the data format (for example, a character string of character code UTF-8) can be grasped from the description on the source file 111 and the translation option. Therefore, the compiler 120 grasps the data format based on the translation options of the source file 111 and the like, and records the data format of the data in the data change history 115 . Also, the compiler 120, for example, takes a file in which data and its data format are associated with each other together with the source file 111 as an input at the time of compiling, grasps the data format based on the file, and transfers the data format of the data to the data change history 115. It can also be recorded.

[Step S<b>105 ] The compiler 120 adds a machine language instruction corresponding to the interpreted statement to the execution file 112 .
[Step S<b>106 ] The compiler 120 adds to the executable file 112 a machine language instruction for recording the changed value of the data to be changed in the data change history 115 . At this time, the compiler 120 records, for example, the changed value of the data to be recorded, the address of the data, the name of the data corresponding to the address, the data format, and the like.

[Step S107] The compiler 120 determines whether the interpretation of the last instruction of the program described in the source file 111 has been completed. Compiler 120 terminates compilation when interpretation is completed up to the last instruction. If there is an uninterpreted instruction, the compiler 120 advances the process to step S101.

Compilation is executed by the compiler 120 in this manner, and an execution file 112 is generated in which processing is described by machine language instructions. In the above description, the processing in the development machine 100a having the same execution environment as that of the migration source is shown, but the processing procedure shown in FIG. compilation is performed.

FIG. 7 is a diagram showing an example of compilation. FIG. 7 shows an example of compiling a gram source file 111 written in the COBOL language. The file name of the source file 111 is "a.cob", and the program described in the source file 111 is "PROG-A". Note that the contents of the execution file 112 are not the machine language instructions themselves, but the meanings of the written instructions.

For example, the compiler 120 generates instructions that record the current value of the data being operated on before and after every statement that describes a data change. An example of generating an instruction for recording a data value for a statement "READ FILE-1." (line number "000100") in a program will be described in detail below.

Compiler 120 understands the sentence specification of the language. As a result of parsing the statement, the compiler 120 can therefore know which data the statement may change. In the case of the READ statement (command statement for reading data from the file) of the source file 111 shown in FIG. 7, the compiler 120 recognizes the following matters.
・A READ statement may rewrite the data area WK-RECORD.
• From the definition of WK-RECORD, WK-RECORD consists of the following terminal items.
WK-ITEM-1: 4 bytes WK-ITEM-2: 8 bytes Compiler 120 generates instructions around the instruction for the READ statement in this example to record the values of the data areas that may change. This instruction generation is performed for each data area that may be changed. In this example, WK-RECORD is the only data area that can be changed, so compiler 120 generates instructions to record data values only in WK-RECORD. However, the compiler 120 does not generate the instructions for WK-RECORD, but outputs them in order for each terminal data item (WK-ITEM-1 and WK-ITEM-2 in this case).

As a result, instructions for recording WK-ITEM-1 and WK-ITEM-2 are added to the execution file 112 before and after the instruction corresponding to "READ FILE-1."

The “instruction to record the value of the data area” is, for example, a run-time function readout instruction that has the function of recording the data value in the data change history 115 . In that case, the compiler 120 generates an instruction that passes the following information to the run-time function in order to record the value of the data in the data change history 115.
- The position of the sentence to be recorded (in the example of FIG. 7, the line "000100" of "a.cob")
- Event type (whether before or after executing the statement to be recorded)
・Start address of data area ・Size of data area ・Data name (name qualified to uniquely identify data within execution process (eg PROG-A/WK-RECORD/WK-ITEM-1))
Data format The compiler 120 determines the data format of each data area based on the following information, for example.
・Default value of COBOL according to data type (many are set for each execution environment)
・Specification by COBOL translation options (for example, rewriting of default values by the user)
• Explicit description for data on source file 111 In this way, an executable file 112 is generated that includes instructions for recording data values. Similarly, the execution file 142 is also generated in the development machine 100b having the destination execution environment. Then, the execution files 112 and 142 are executed in the development machines 100a and 100b having respective execution environments of the migration source and the migration destination, and the data values before and after the change are recorded in the data change histories 115 and 145, respectively. By comparing the data change histories 115 and 145 for each execution environment between the migration source and the migration destination, a comparison result indicating whether or not there is an incompatible operation is generated.

FIG. 8 is a diagram illustrating an example of data change history generation and comparison processing. For example, in response to an input instructing the development machine 100a to execute the execution file 112, the execution unit 130 reads the machine language program 112a from the execution file 112 and executes the program 112a. The execution unit 130 reads the corresponding runtime 114 a from the runtime library 114 when executing an instruction for recording data values (an instruction to call a runtime function). The execution unit 130 then stores the data values in the data change history 115 by executing the instructions described in the runtime 114a.

In response to an input instructing the development machine 100b to execute the execution file 142, the execution unit 160 reads the machine language program 142a from the execution file 142 and executes the program 142a. The execution unit 160 reads the corresponding runtime 144a from the runtime library 144 when executing an instruction to record a data value (an instruction to call a runtime function). The execution unit 160 then stores data values in the data change history 145 by executing the instructions described in the runtime 144a.

When execution of execution file 112 by execution unit 130 and execution of execution file 142 by execution unit 160 are completed, data history comparison unit 170 compares data change history 115 and data change history 145 and outputs comparison result 171. do. The comparison result 171 indicates whether the applications provided by the executable files 112 and 142 are compatible in operation before and after migration.

FIG. 9 is a diagram showing an example of a data change history. When the execution unit 130 executes the program 112a, the runtime 114a records log records including data values before and after each statement in the program in the data change history 115 in order of execution of the statements. The example of FIG. 9 shows log records recorded in the data change history 115 when the same READ statement is executed twice by repeated processing.

In the data change history 115, log records are divided not by the entire data area to be operated (WK-RECORD in this case) but by terminal items (WK-ITEM-1 and WK-ITEM-2 in this case). output in order.

A log record contains serial number, source file name, line number, event type, address, size, value, data name, and data format information. The serial number is an identification number assigned to each log record, and numbers are assigned in ascending order starting from 1 in order of earliest recording to the log record. The source file name is the file name of the source file 111 from which the executed execution file 112 was generated. The line number is the line number in the source file 111 where the command in the source file 111 corresponding to the command that caused the output of the log record is described. The event type is information indicating whether the log record is a log before execution of an instruction involving data change (pre-execution) or a log after execution of an instruction involving data change (post-execution). Address is the address in memory of the data to be changed. Size is the number of bytes of data to be changed. Value is the value of the data before or after the data is changed. The data name is a name qualified so as to uniquely identify the corresponding data within the execution unit 130 that executes the program 112a. The data format is information indicating the data format of the data to be changed.

In the example of FIG. 9, the data format of WK-ITEM-1 is big endian binary integer. The data format of WK-ITEM-2 is Japanese EUC character string.
The data change history 145 generated by the development machine 100b having the migration destination item environment also includes the same type of information as the data change history 115. FIG. In the data change history 115 and the data change history 145, log records having the same serial number have a corresponding relationship. The data history comparison unit 170 compares the log records that have a corresponding relationship, and determines whether there is compatibility before and after the transition of the processing corresponding to the statement of the line number indicated in the log record.

FIG. 10 is a flowchart illustrating an example of the procedure of data change history comparison processing. The processing shown in FIG. 10 will be described below along with the step numbers.
[Step S201] The data history comparison unit 170 initializes the variable i indicating the serial number of the log record to be compared to "1".

[Step S202] The data history comparison unit 170 acquires the i-th log record (serial number is i) from both the data change histories 115 and 145, respectively.
[Step S203] The data history comparison unit 170 determines whether the data names indicated in the two acquired log records are the same. If the data names are the same, data history comparison unit 170 advances the process to step S205. If the data names are different, data history comparing section 170 advances the process to step S204.

[Step S204] The data history comparison unit 170 determines that the programs executed to generate the data change histories 115 and 145 do not match, and ends the comparison processing of the data change histories 115 and 145. FIG.

[Step S205] The data history comparison unit 170 determines whether there is a difference between the data formats indicated in the two acquired log records. If the data formats are different, data history comparison unit 170 advances the process to step S206. If the data formats are the same, data history comparison section 170 advances the process to step S209.

[Step S206] The data history comparison unit 170 determines whether the difference in data format is a difference in floating point numbers. Data history comparison unit 170 advances the process to step S208 if there is a floating-point difference. If the difference is other than floating point, data history comparison unit 170 advances the process to step S207.

[Step S207] The data history comparison unit 170 converts the data format of one data into the data format of the other data. As a result, the data formats of the two log records to be compared match. After that, the data history comparison unit 170 advances the process to step S209.

[Step S208] The data history comparison unit 170 converts the data formats of both log records to be compared into a predetermined data format. For example, the data history comparison unit 170 converts floating point data into a numeric format (for example, a string of numbers and decimal points).

[Step S209] The data history comparison unit 170 compares data values indicated in log records to be compared.
[Step S210] The data history comparison unit 170 determines whether the data values are the same. If the data values are the same, data history comparison unit 170 advances the process to step S211. If the data values are different, data history comparing section 170 advances the process to step S212.

[Step S211] The data history comparison unit 170 outputs a comparison result record in the comparison result 171 indicating that the operation compatibility has been confirmed. After that, the data history comparison unit 170 advances the process to step S213.

[Step S212] The data history comparison unit 170 outputs a comparison result record indicating detection of an incompatible operation in the comparison result 171. FIG.
[Step S213] The data history comparison unit 170 adds 1 to the variable i.

[Step S214] The data history comparing unit 170 determines whether or not the data change history 115, 145 includes the i-th log record. Data history comparison unit 170 advances the process to step S202 if there is an i-th log record. If there is no i-th log record, the data history comparison unit 170 ends the data change history comparison process.

In this way, log records with the same serial number are compared to determine whether or not there is an incompatible operation due to a difference in data format.
FIG. 11 is a diagram showing a first example of data comparison processing. The 13th log record of the data change history 115 acquired on the execution environment of the migration source indicates that WK-ITEM-1 was translated as a binary integer with a big endian endian. . The 14th log record of the data change history 115 indicates that WK-ITEM-2 has been translated as a Japanese EUC character string.

The 13th log record of the data change history 145 acquired on the migration destination execution environment indicates that WK-ITEM-1 was translated as a binary integer and endian as little endian. . The 14th log record of the data change history 145 indicates that WK-ITEM-2 was translated as a UTF-16LE character string.

When comparing log records, the data history comparison unit 170 first confirms that the data names match. If the data names do not match, the data history comparison unit 170 determines that the processing logic of the programs is different (they are not the same programs), and stops comparison. Even if the logic of the program is the same, the addresses shown in the log records to be compared may be different because the addresses differ depending on the execution environment. In the example of FIG. 11, the data name of the 13th log record is both "WK-ITEM-1". The data name of the 14th log record is both "WK-ITEM-2". Therefore, both data names match.

If the data names match, the data history comparison unit 170 determines whether the data formats match. On the other hand, if the data formats do not match, the data history comparison unit 170 compares the data values after making the data formats match.

In the case of the 13th log record comparison, the data history comparison unit 170 changes the endian of the log record data in the data change history 115 acquired based on the migration source execution environment from big endian to little endian. there is Then, the data history comparison unit 170 compares data values with the same endian. The meaning represented by the data value of the 13th log record is "123456" when expressed in decimal. Therefore, the data history comparison unit 170 outputs a comparison result record 171a indicating compatibility confirmation as the comparison result 171. FIG.

In the case of the 14th log record comparison, the data history comparison unit 170 converts the character code of the log record data in the data change history 115 acquired based on the migration source execution environment into UTF16-LE. The data history comparison unit 170 aligns the character codes and compares the data values. The data values of the 14th log record are already the same before character code conversion. This is caused, for example, by omission of data format conversion when the data files 143a, 143b, . . . are generated. By converting one of the character codes to be compared that have the same value, the result of the comparison will be a mismatch. Therefore, the data history comparison unit 170 outputs, as the comparison result 171, a comparison result record 171b indicating detection of incompatible operation.

The comparison result 171 stores comparison result records 171a and 171b each time log records are compared. Comparison result records 171a and 171b include result, serial number, source file name, line, and event type. The result is information indicating the presence or absence of compatibility, and "OK" is set when compatibility is confirmed, and "NG" is set when incompatible operation is detected. The serial number is the serial number of the compared log records. The source file name is the file name of the source file 111, 141 corresponding to the execution file 112, 142 executed to generate the data change history 115, 145 to be compared. Line is the line number of the statement in the source file 111, 141 corresponding to the instruction recording the compared log record. The event type is information indicating whether the compared log record is a log before execution of an instruction with data modification (pre-execution) or a log after execution of an instruction with data modification (post-execution). is. The data name is the data name of the data indicated in the compared log records.

The comparison result records 171a and 171b also include the data format, size, and value of the log record data of the migration source, and the data format, size, and value of the log record data of the migration destination.

For example, the result of the comparison result record 171a is "OK". That is, it indicates that compatibility has been confirmed. The result of the comparison result record 171b is "NG". That is, it indicates that an incompatible operation has been detected.

FIG. 12 is a diagram showing a second example of data comparison processing. FIG. 12 shows an example of comparison processing when the floating-point formats are different.
The 23rd log record of the data change history 115 acquired on the migration source execution environment indicates that WK-ITEM-1 was translated as a binary integer with a big endian endian. . The twenty-fourth log record of data change history 115 shows that WK-ITEM-2 was translated as a floating point called host format floating point.

The 23rd log record of the data change history 145 acquired on the destination execution environment indicates that WK-ITEM-1 was translated as a binary integer and endian as little endian. . The 24th log record of data change history 145 shows that WK-ITEM-2 was translated as a floating point called IEEE (Institute of Electrical and Electronics Engineers) floating point.

In the case of the 23rd log record comparison, the data history comparison unit 170 changes the endian of the log record data in the data change history 115 acquired based on the migration source execution environment from big endian to little endian. there is Then, the data history comparison unit 170 compares data values with the same endian. The meaning represented by the data value of the 23rd log record is "123456" when expressed in decimal. Therefore, the data history comparison unit 170 outputs a comparison result record 171c indicating compatibility confirmation as the comparison result 171. FIG.

When comparing the 24th log record, the data history comparison unit 170 converts the floating point data of both log records into numerical values. The data history comparison unit 170 compares numerical values represented by data values (floating point numbers). The numerical values represented by the data values of the 24th log record are both "0.125". Therefore, the data history comparison unit 170 outputs a comparison result record 171d indicating compatibility confirmation as the comparison result 171. FIG.

For example, comparison result records 171c and 171d are both "OK". That is, it indicates that compatibility has been confirmed.
In this way, if the data formats of both log records to be compared are different, the data history comparison unit 170 unifies the data formats to one of the data formats or a predetermined data format before comparing the data values. do. This makes it possible to determine the identity of the meaning represented by the data values.

Note that the data history comparison unit 170 compares the data values as they are if the data formats match. When the data history comparing unit 170 detects that the data values are different as a result of the comparison, it determines that an incompatible operation has occurred in the migration destination execution environment, and creates a comparison result record indicating that fact. Output to the comparison result 117 .

The comparison result 117 indicates whether compatibility was confirmed by comparison (OK) or whether incompatible operation was detected (NG) in the order of the compared log records. By displaying the comparison result 171 on the monitor 21, the operator can specify the line of the source files 111 and 141 corresponding to the log record in which the incompatible operation was detected earliest. The row where the incompatible operation is detected earliest is presumed to be the source of the occurrence of the incompatible operation. That is, by referring to the comparison result 171, the operator can easily identify the cause of the occurrence of the incompatible operation.

Compilers 120 and 150 also add instructions for recording data values before and after instructions that modify data. As a result, it is possible to easily confirm from the comparison result what kind of data conversion was performed at the location where the incompatible operation occurred, and to quickly identify the cause of the incompatible operation.

[Other embodiments]
In the second embodiment, the development machines 100a and 100b are prepared separately from the operation machines 200a and 200b, but application compatibility may be verified using the operation machines 200a and 200b.

In the second embodiment, the compilers 120 and 150 add instructions for recording data values before and after instructions that change data. You can add instructions. For example, the development machines 100a and 100b can analyze a machine language program in an executable file that has already been generated, and add instructions for recording data values before and after instructions that change data.

In the second embodiment, an instruction for recording data values is added both before and after an instruction that changes data. An instruction may be added to record the value of the data only in the latter one.

Although the embodiment has been exemplified above, the configuration of each part shown in the embodiment can be replaced with another one having the same function. Also, any other components or steps may be added. Furthermore, any two or more configurations (features) of the above-described embodiments may be combined.

1 verification target program 2 first execution program 3 second execution program 4 first data 5 second data 6 first data change history 7 second data change history 10 information processing device 11 storage unit 12 processing unit 12a first program execution environment 12b second program execution environment

Claims (6)

a first execution program for executing, in a first program execution environment, a process according to a verification target program including a verification target instruction that changes a data value, based on the verification target instruction; Add a first record command to record the change content by the first data change command set in
By executing the first execution program in the first program execution environment, acquiring a first data change history in which change contents of the value of the first data according to the first data change instruction are recorded. ,
A second data change set in the second execution program based on the verification target instruction in a second execution program for executing processing according to the verification target program in a second program execution environment. Add a second recording command to record the changes made by the command,
By executing the second execution program in the second program execution environment, acquiring a second data change history in which changes to the value of the second data by the second data change instruction are recorded. ,
detecting an incompatible operation by comparing the first data change history and the second data change history;
A verification program that causes a computer to perform a process. Acquiring the first data change history includes acquiring the first data change history including the value before or after the change of the first data,
Acquiring the second data change history includes acquiring the second data change history including the value before or after the change of the second data,
In detecting an incompatible operation, the meaning represented by the value of the first data indicated in the first data change history and the value of the second data indicated in the second data change history. compare the meanings of the terms and determine that incompatible behavior occurs when different meanings are expressed;
The verification program according to claim 1. In acquiring the first data change history, the first data change includes a first data format required for the first data and a value before or after the change of the first data. get history,
In acquiring the second data change history, the second data change includes a second data format required for the second data and a value before or after the change of the second data. get history,
detecting an incompatible operation based on the first data format indicated in the first data change history and the second data format indicated in the second data change history; Converting the data format of at least one of and the second data, and comparing the values of the first data and the second data;
3. The verification program according to claim 2. Acquiring the first data change history includes acquiring the first data change history including a first data name that identifies the first data,
Acquiring the second data change history includes acquiring the second data change history including a second data name that identifies the second data,
Detecting an incompatible operation includes comparing the first data name indicated in the first data change history with the second data name indicated in the second data change history;
The verification program according to any one of claims 1 to 3. a first execution program for executing, in a first program execution environment, a process according to a verification target program including a verification target instruction that changes a data value, based on the verification target instruction; Add a first record command to record the change content by the first data change command set in
By executing the first execution program in the first program execution environment, acquiring a first data change history in which change contents of the value of the first data according to the first data change instruction are recorded. ,
A second data change set in the second execution program based on the verification target instruction in a second execution program for executing processing according to the verification target program in a second program execution environment. Add a second recording command to record the changes made by the command,
By executing the second execution program in the second program execution environment, acquiring a second data change history in which changes to the value of the second data by the second data change instruction are recorded. ,
detecting an incompatible operation by comparing the first data change history and the second data change history;
A verification method in which processing is performed by a computer. a first execution program for executing, in a first program execution environment, a process according to a verification target program including a verification target instruction that changes a data value, based on the verification target instruction; By adding a first recording instruction for recording the change content by the first data modification instruction set in the first data modification instruction, and executing the first execution program in the first program execution environment, A second data change history for acquiring a first data change history in which changed contents of a first data value by a data change instruction are recorded, and executing a process according to the verification target program in a second program execution environment. adding, to the execution program, a second recording instruction for recording changes made by a second data modification instruction set in the second execution program based on the verification target instruction, and creating the second program execution environment; by executing the second execution program in the second data change instruction, acquiring a second data change history in which changes to the value of the second data are recorded, and performing the first data change a processing unit that detects an incompatible operation by comparing the history with the second data change history;
Information processing device having

Images