Verification program, verification method, and information processing device

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

[Technical Field]

[0001] The present invention relates to a verification program, a verification method, and an information processing device. [Background technology]

[0002] Among the application software (hereafter simply referred to as "applications") used in business, there are some that were developed long ago and are still in use today, especially applications written in the COBOL language.

[0003] On the other hand, the execution environment (hardware, OS (Operating System), character code system, etc.) in which applications are executed changes over time. Therefore, in order to continue operating the same application over the long term, the application must be migrated to a new execution environment in line with the changes in the execution environment.

[0004] 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 formats (CPU (Central Processing Unit) bit width, endian, floating-point format, character code, etc.) handled by the execution environments before and after the migration may be different. In this case, even if there is no change to the processing logic of the application program, there is a possibility that unintended behavior (incompatible behavior) may occur when the application is executed due to differences in data formats. For this reason, when changing the application's execution environment, operators must verify operation in the destination environment.

[0005] Various technologies have been proposed to automate the verification process that accompanies the migration of application execution environments. For example, a migration test support system has been proposed that, when analyzing the differences between a current system and a new system in a system migration test, excludes from the analysis the parts of the application that have been modified, making it easier to analyze the causes of the differences between the old and new systems. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] Japanese Patent Application Laid-Open No. 2012-203580 Summary of the Invention [Problem to be solved by the invention]

[0007] However, with conventional technology, it is difficult to identify in advance the cause of incompatible behavior that occurs due to differences in data formats between the execution environments before and after migration. For example, an operator would test run the application in the destination environment, and if an incompatible behavior occurs, they would perform code review or debug using a debugger, tracing the logic back from the incompatible behavior to identify the cause. This method requires manual work to identify the cause, which is time-consuming. Furthermore, if an incompatible behavior occurs in a situation that was not targeted by the test, it cannot be detected. If this incompatible behavior becomes apparent after the application goes into operation in the destination environment, it could cause a problem in the production environment.

[0008] In one aspect, the present invention aims to make it easier to identify the location of an incompatible operation. [Means for solving the problem]

[0009] In one proposal, a verification program is provided that causes a computer to perform the following processes. The computer adds a first recording instruction to a first execution program for executing processing in a first program execution environment according to a program to be verified, the first execution program including a verification target instruction that modifies a data value, the first recording instruction recording changes made by a first data modification instruction set in the first execution program based on the verification target instruction. The computer executes the first execution program in the first program execution environment to obtain a first data modification history recording changes made to the value of the first data by the first data modification instruction. The computer adds a second recording instruction to a second execution program for executing processing in a second program execution environment according to the program to be verified, the second recording instruction recording changes made by a second data modification instruction set in the second execution program based on the verification target instruction. The computer executes the second execution program in the second program execution environment to obtain a second data modification history recording changes made to the value of the second data by the second data modification instruction. The computer then detects incompatible operations by comparing the first data modification history with the second data modification history. [Effects of the Invention]

[0010] According to one aspect, it is possible to easily identify the location where an incompatible operation occurs. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 2 illustrates an example of a verification method according to the first embodiment. [Figure 2] FIG. 10 illustrates an example of a system configuration according to a second embodiment. [Figure 3] FIG. 2 illustrates an example of hardware of a development machine. [Figure 4] FIG. 10 is a diagram illustrating an example of functions of an operation development system for verifying the operation of an application. [Figure 5] FIG. 10 is a diagram illustrating an example of a generation status of an execution file. [Figure 6] FIG. 10 illustrates an example of a compilation procedure. [Figure 7]FIG. 10 is a diagram illustrating an example of compilation. [Figure 8] FIG. 10 illustrates an example of a process for generating and comparing data change histories; [Figure 9] FIG. 10 is a diagram illustrating an example of a data change history. [Figure 10] 10 is a flowchart illustrating an example of a procedure for a data change history comparison process. [Figure 11] FIG. 10 is a diagram illustrating a first example of a data comparison process. [Figure 12] FIG. 10 is a diagram illustrating a second example of the data comparison process. DETAILED DESCRIPTION OF THE INVENTION

[0012] The present embodiment will be described below with reference to the drawings. Note that each embodiment can be implemented in combination with a plurality of other embodiments within a range that does not contradict each other. [First embodiment] First, we will explain the first embodiment. The first embodiment is a verification method that makes it possible to easily identify the location where incompatible behavior occurs due to differences in data formats when migrating the execution environment of a program.

[0013] Fig. 1 is a diagram illustrating an example of a verification method according to a first embodiment. Fig. 1 illustrates an example of an information processing device 10 that realizes the verification method. The information processing device 10 can implement the verification method by executing a verification program.

[0014] To implement the verification method, the information processing device 10 includes a memory unit 11 and a processing unit 12. The memory unit 11 is, for example, a memory or storage device included in the information processing device 10. The processing unit 12 is, for example, a processor or an arithmetic circuit included in the information processing device 10.

[0015] The storage unit 11 stores a program to be verified 1. The program to be verified 1 is, for example, a source program written in a high-level language. The program to be verified 1 includes an instruction to be verified that changes the value of data.

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

[0017] The first program execution environment 12a and the second program execution environment 12b are program execution environments including hardware, an OS, and the like. The first program execution environment 12a and the second program execution environment 12b can be realized using, for example, a virtual machine. If the information processing device 10 is a computer system including multiple computers, the first program execution environment 12a and the second program execution environment 12b may be realized on different computers. The first program execution environment 12a and the second program execution environment 12b differ mainly in the data format of the data they handle (e.g., CPU bit width, endian, floating-point format, character code, etc.).

[0018] Here, it is assumed that a user of the information processing device 10 plans to migrate a service that is running on a first program execution environment 12a using an execution program generated based on the program to be verified 1 to a second program execution environment 12b. In this case, the user performs an operation verification to determine whether a program compiled from the program to be verified 1 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.

[0019] The processing unit 12 compiles the program 1 to be verified in the first program execution environment 12a, for example, to generate a first execution program 2 for executing the processing described in the program 1 to be verified in the first program execution environment 12a. At this time, the processing unit 12 adds a first recording instruction to the first execution program 2, which records changes made by a first data modification instruction set in the first execution program 2 based on the instruction to be verified. Furthermore, the processing unit 12 executes the first execution program 2 in the first program execution environment 12a, thereby acquiring a first data modification history 6 that records changes made to the value of first data 4 by the first data modification instruction.

[0020] Furthermore, the processing unit 12 generates a second execution program 3 for executing the processing described in the program 1 to be verified in the second program execution environment 12b, for example, by compiling the program 1 to be verified in the second program execution environment 12b. At this time, the processing unit 12 adds a second recording instruction to the second execution program 3, which records changes made by a second data modification instruction set in the second execution program 3 based on the instruction to be verified. Furthermore, the processing unit 12 executes the second execution program 3 in the second program execution environment 12b, thereby acquiring a second data modification history 7 that records changes made to the value of second data 5 by the second data modification instruction.

[0021] The second data 5 is data to which a value having the same meaning as the first data 4 is set if there is no incompatible operation, for example. For example, if the first data 4 is a character string, a value indicating the same character string is set in the second data 5. 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 differs from the character code system representing the character string of the second data 5. 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.

[0022] 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 detect incompatible operations due to differences in data formats. For example, the processing unit 12 acquires the first data change history 6, which includes the pre-change value or post-change value of the first data 4. The processing unit 12 also acquires the second data change history 7, which includes the pre-change value or post-change value of the second data 5. The processing unit 12 then compares the meaning represented by the value of the first data 4 shown in the first data change history 6 with the meaning represented by the value of the second data 5 shown in the second data change history 7, and determines that an incompatible operation exists if the meanings are different. In other words, if the meanings are different, the first data change instruction and the second data change instruction are instructions set based on the same verification target instruction, but they are performing data change operations (incompatible operations) to values ​​that represent different meanings.

[0023] For example, the first data modification command of the first execution program 2 is intended to modify the value of data in a standard data format in the first program execution environment 12a. In this case, based on the first data modification command, the first data 4 is interpreted as data in a standard data format in the first program execution environment 12a, and modification processing is performed.

[0024] Similarly, it is assumed that the second data modification command of the second execution program 3 is intended to modify the value of data in a standard data format in the second program execution environment 12b. In this case, based on the second data modification command, the second data 5 is interpreted as data in a standard data format in the second program execution environment 12b, and modification processing is performed.

[0025] In this case, if the data format of the second data 5 is different from the expected data format, the meaning represented by the value of the second data 5 after the change will be different from the meaning represented by the value of the first data 4 after the change. As a result, it is determined that there is an incompatible operation (data change to a value representing a different meaning).

[0026] When detecting an incompatible operation based on a difference in data format, for example, the processing unit 12 acquires a first data change history 6 including a first data format required for the first data 4 and a value before or after the change of the first data 4. The processing unit 12 also acquires a second data change history 7 including a second data format required for the second data 5 and a value before or after the change of the second data 5. The processing unit 12 then converts the data format of at least one of the first data 4 and the second data 5 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. The processing unit 12 then compares the values ​​of the first data 4 and the second data 5.

[0027] 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 Code) character string." The second data change history 7 indicates that the data value is "A4A2A4A4A4A68140" and that the data format is "UTF (Unicode Transformation Format)-16LE (Little Endian) character string." In the example of FIG. 1, the data values ​​indicated in the first data change history 6 and the second data change history 7 are the same. However, the character encoding system interpreted during execution of the first execution program 2 is different from the character encoding system interpreted during execution of the second execution program 3. This can occur when Japanese EUC data is input to the second program execution environment 12b as the target for processing by the second execution program 3.

[0028] 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 (Japanese EUC character code) into UTF-16LE character code, and compares the converted value of the first data 4 with the value of the second data 5. The values ​​then do 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 has occurred in the part of the verification target instruction in the verification target program 1.

[0029] In this way, the information processing device 10 can easily identify the location of the incompatible operation and can detect the incompatible operation caused by the difference in data format with high accuracy. For example, if the character encoding system of the second data 5 is different from the character encoding system assumed in the second data modification command, and the character code of the second data 5 is a value that does not exist in the assumed character encoding system, it has traditionally been easy to detect an irregularity in the second data 5. However, in general, if the character encoding set as the value of the second data 5 is a character encoding that also exists in the character encoding system assumed in the second data modification command, it is difficult to detect this as an error. In many cases, the processing continues without detecting the error, and the problem becomes apparent as garbled characters.

[0030] In response to this, the processing unit 12 detects incompatible operations by comparing the first data change history 6 with the second data change history 7. As a result, even if the character code of the second data 5 also exists in the character code system assumed in the second data change command, if the character code system of the second data 5 is different from the assumed one, it can be detected as an incompatible operation. Therefore, it is possible to accurately detect incompatible operations caused by differences in data formats.

[0031] If an incompatible operation occurs due to a difference in data format, the user may, for example, review the processing logic up to the verification target instruction, which is the source of the problem, and modify the verification target program 1 so that it can correctly process data even if the data is input in a format different from the expected one. Alternatively, the user may check the data being read by the verification target instruction, and configure the environment in the second program execution environment 12b so that the data format of the input data is the expected data format.

[0032] The processing unit 12 may also compare the data names of the first data 4 and the second data 5 to confirm that data with the same data name are being compared. In this case, the processing unit 12 acquires a first data change history 6 that includes a first data name that identifies the first data 4. The processing unit 12 also acquires a second data change history 7 that includes a second data name that identifies the second data 5. The processing unit 12 then compares the first data name shown in the first data change history 6 with the second data name shown in the second data change history 7 to confirm 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, will be the same as the data name of the second data 5, whose value is changed by the second data change instruction. Therefore, if the data name of the first data does not match the second data name, it can be determined that the processing logics are different (the two execution programs are not equivalent programs). That is, when the processing by first execution program 2 that has been executed in first program execution environment 12a is migrated to second program execution environment 12b, it can be confirmed that the processing logic has not been changed.

[0033] In addition to character codes, the data format of the data may be endian, floating-point representation, or the like. If the floating-point representation formats of the first data 4 and the second data 5 are different, the processing unit 12 may unify the data format of either data, possibly resulting in a deterioration in the accuracy of the floating-point numerical values. Therefore, if the floating-point representation formats of the first data 4 and the second data 5 are different, the processing unit 12 may convert the first data 4 and the second data 5 into a third representation format. For example, the processing unit 12 may convert the first data 4 and the second data 5 into numerical values ​​(arrays of digits and decimal points) indicated by the values ​​of those data. This allows the meanings (numerical values) expressed by the values ​​(floating-point) of the first data 4 and the second data 5 to be accurately compared.

[0034] 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 to check for incompatible operations due to differences in data formats.

[0035] Fig. 2 is a diagram showing an example of a system configuration according to the second embodiment. Fig. 2 shows an example of a system configuration in which, when migrating the execution environment of an application running on an operation system 200, application operation verification is performed in advance using a development system 100.

[0036] 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 operation system 200 includes two operation machines 200a and 200b used to provide services using applications.

[0037] Development machines 100a and 100b are computers prepared for application development and testing, while operation machines 200a and 200b are computers prepared for executing application-based processes and operating various services.

[0038] Let's assume that an application that was running on operation machine 200a is migrated to operation machine 200b. Operation machine 200b has a different operating environment from operation machine 200a. In this case, in development system 100, an operating environment identical to that of source operation machine 200a is built on development machine 100a, and an operating environment identical to that of destination operation machine 200b is built on development machine 100b.

[0039] Development machines 100a and 100b may be virtual machines that replicate the operating environments of operation machines 200a and 200b, respectively. If development machines 100a and 100b are both virtual machines, both development machines 100a and 100b can be built within the same computer.

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

[0041] The memory 102 is used as the main storage device of the development machine 100a. The memory 102 temporarily stores at least a portion of the OS program and application programs to be executed by the processor 101. The memory 102 also stores various data used in processing by the processor 101. The memory 102 may be a volatile semiconductor storage device such as a RAM (Random Access Memory).

[0042] The 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.

[0043] The storage device 103 electrically or magnetically writes and reads data to and 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 the OS program, application programs, and various data. Note that the storage device 103 may be, for example, an HDD (Hard Disk Drive) or an SSD (Solid State Drive).

[0044] The GPU 104 is an arithmetic unit that performs image processing and is also called a graphics controller. The GPU 104 is connected to a monitor 21. The GPU 104 displays an image on the screen of the monitor 21 in accordance with an instruction from the processor 101. The monitor 21 may be a display device using organic EL (Electro Luminescence) or a liquid crystal display device.

[0045] The input interface 105 is connected to a keyboard 22 and a mouse 23. The input interface 105 transmits signals sent from the keyboard 22 and the mouse 23 to the processor 101. The mouse 23 is an example of a pointing device, and other pointing devices can also be used. Examples of other pointing devices include a touch panel, a tablet, a touch pad, and a trackball.

[0046] The optical drive device 106 uses a laser beam or the like to read data recorded on an optical disc 24 or write data to the optical disc 24. The optical disc 24 is a portable recording medium on which data is recorded so that it can be read by reflected light. The optical disc 24 includes a DVD (Digital Versatile Disc), a DVD-RAM, a CD-ROM (Compact Disc Read Only Memory), a CD-R (Recordable) / RW (Rewritable), and the like.

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

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

[0049] Development machine 100a can be realized with the hardware described above. The other development machine 100b and operation machines 200a and 200b can also be realized with hardware similar to that of development machine 100a. Furthermore, information processing device 10 shown in the first embodiment can also be realized with hardware similar to that of development machine 100a shown in FIG. 3.

[0050] The development machine 100a realizes the processing functions of the second embodiment by executing a program recorded on, for example, a computer-readable recording medium. Programs describing the processing to be executed by the development machine 100a can be recorded on various recording media. For example, the program to be executed by the development machine 100a can be stored in the storage device 103. The processor 101 loads at least a portion of the program from 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 on a portable recording medium such as the optical disk 24, memory device 25, or memory card 27. A program stored on a portable recording medium can be installed on the storage device 103 under the control of, for example, the processor 101, and then executed. The processor 101 can also directly read and execute the program from the portable recording medium.

[0051] For example, when an operator who provides a service by executing an application on operation machine 200a migrates the application to another operation machine 200b, the operator verifies compatibility of the application's execution environment in advance, for example, using development machines 100a and 100b. Compatibility verification verifies whether unintended operations (incompatible operations) are executed due to differences in data formats.

[0052] Here, examples of incompatible operations caused by differences in data formats include the following. The first example is incompatible behavior due to differences in endianness. Endianness is the type of order in which multiple bytes are arranged. There are types of endianness, such as big endian and little endian. In big endianness, data in bytes is arranged from the most significant byte first. In little endianness, data in bytes is arranged from the least significant byte first.

[0053] There are cases where a program execution environment that assumes big-endian data input is migrated to one that assumes little-endian data input. For example, the source program execution environment reads four bytes of a byte sequence in network byte order (big-endian) from the network and processes them as a binary integer. In this case, the destination program execution environment may handle the retrieved data as little-endian. In this case, because the endianness is different, if the big-endian data is executed as is, it will be processed as an integer value different from the original value, and unintended results will be output.

[0054] The second example is incompatible behavior due to differences in character codes. For example, the OS on which a program runs may be migrated from an OS with an EUC system character code to an OS with a UTF-16 system character code. In this case, the processing logic of the destination computer assumes EUC, so if the acquired character data is input as UTF-16, unintended results will be output.

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

[0056] 4 is a diagram showing an example of the functions of the behavior development system for verifying the behavior of an application. A development machine 100a has a storage unit 110, a compiler 120, and an execution unit .

[0057] The storage unit 110 has a source file 111, an executable file 112, multiple data files 113a, 113b,..., a runtime library 114, and a data change history 115. The source file 111 is a program file in which the processing content of an application is written in a high-level language. The executable file 112 is a program file in executable machine language generated based on the source file 111. The data files 113a, 113b,... are files in which data to be used when the executable file 112 is executed is set. The runtime library 114 is a file in which runtimes (software components) available when the executable file 112 is executed are registered. The data change history 115 is a log file in which the history of data changes made when the executable file 112 executes the application is stored.

[0058] Compiler 120 translates (compiles) source file 111 into machine language. That is, compiler 120 interprets the program written in source file 111 and generates executable file 112 that is compatible with the program execution environment of development machine 100a. Note that the program execution environment of development machine 100a is the same as that of source operation machine 200a in operation system 200, so the generated executable file 112 is also compatible with source operation machine 200a. When compiler 120 detects an instruction that changes data in a data area, it adds an instruction to executable file 112 that records the value of the data before and after the change.

[0059] The execution unit 130 is a process that executes the executable file 112. When there is a data read instruction to be processed during the execution of the executable file 112, the execution unit 130 reads the corresponding data from, for example, data files 113a, 113b, .... Furthermore, when a runtime is called during the execution of the executable file 112, the execution unit 130 obtains the corresponding runtime from the runtime library 114 and executes the obtained runtime. For example, when a runtime that records specified data in the data change history 115 is provided, the execution unit 130 calls and executes the runtime when executing an instruction to record the value of the data. When the execution unit 130 executes the executable file 112, the values ​​before and after the change of data that was changed during the execution of the executable file 112 are stored in the data change history 115.

[0060] The development machine 100b includes 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 executable file 142, multiple data files 143a, 143b, ..., a runtime library 144, and a data change history 115. The source file 141 is a program file with 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 to be used when the executable file 142 is executed is set. The runtime library 144 is a file in which runtimes available when the executable file 142 is executed are registered. The data change history 145 is a log file in which a data change history when the executable file 142 executes an application is stored.

[0061] The data files 143a, 143b, etc. are generated by converting the data format of the data contained in the data files 113a, 113b, etc. held by the development machine 100a, for example, into a data format compatible with the destination program execution environment. When there are a large number of data files 143a, 143b, etc., there is a possibility that some data format conversions may be omitted. Such omitted data format conversions may result in incompatible operations.

[0062] Compiler 150 compiles source file 141 into machine language. That is, compiler 150 interprets the program written in source file 141 and generates executable file 142 that is compatible with the program execution environment of development machine 100b. Note that the program execution environment of development machine 100b is the same as that of destination operation machine 200b in operation system 200, so the generated executable file 142 is also compatible with destination operation machine 200b. When compiler 150 detects an instruction that changes data in a data area, it adds an instruction to executable file 142 that records the value of the data before and after the change.

[0063] The execution unit 160 is a process that executes the executable file 142. When there is a data read instruction to be processed during the execution of the executable file 142, the execution unit 160 reads the corresponding data from, for example, data files 143a, 143b, etc. Furthermore, when a runtime is called during the execution of the executable file 142, the execution unit 160 obtains the corresponding runtime from the runtime library 144 and executes the obtained runtime. For example, when a runtime that records specified data in the data change history 145 is provided, the execution unit 160 calls and executes the runtime when executing an instruction to record the value of the data. When the execution unit 160 executes the executable file 142, the values ​​of data changed during the execution of the executable file 142 before and after the change are stored in the data change history 145.

[0064] The data history comparison unit 170 compares the meanings expressed by the values ​​of the data change histories 115, 145 of both development machines 100a, 100b, and detects incompatible operations. The development system 100 detects an incompatible operation and identifies the location of the cause of the incompatible operation in the following procedure.

[0065] First, compilers 120 and 150 corresponding to the description language of the program written in the source files 111 and 141 generate a program so that the history of all data changes during program execution shown in the execution files 112 and 142 is automatically recorded.

[0066] 5 is a diagram showing an example of how an executable file is generated. For example, in development machine 100a, compiler 120 compiles source file 111 to generate executable file 112. In development machine 100b, compiler 150 compiles source file 141 (a copy of source file 111) to generate executable file 142. When compiling source files 111 and 141, compilers 120 and 150 detect an instruction that modifies data, and add a data recording instruction before and after that instruction.

[0067] Fig. 6 shows an example of the compilation procedure. The process shown in Fig. 6 will be explained below in order of step numbers, taking as an example the case where the compiler 120 in the development machine 100a compiles.

[0068] [Step S101] The compiler 120 selects statements from the source file 111 one by one from the top down, and interprets the processing to be performed according to the selected statements. [Step S102] The compiler 120 determines whether data will be changed by processing according to the interpreted command statement. For example, the compiler 120 determines that data will be changed if the command involves reading data into the data area of ​​the memory 102. If data will be changed, the compiler 120 proceeds to step S104. If data will not be changed, the compiler 120 proceeds to step S103.

[0069] [Step S103] The compiler 120 adds machine language instructions corresponding to the interpreted statements to the executable file 112. After that, the compiler 120 proceeds to step S107.

[0070] [Step S104] The compiler 120 adds to the executable 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, and the like, in addition to the pre-change value of the data to be recorded.

[0071] For example, in a high-level language such as COBOL, the data format (for example, a character string in character code UTF-8) can be determined from the description in the source file 111 and translation options, etc. Compiler 120 therefore determines the data format based on the translation options, etc. of source file 111, and records the data format of the data in data change history 115. Compiler 120 can also use, for example, a file that associates data with its data format as input during compilation along with source file 111, determine the data format based on the file, and record the data format of the data in data change history 115.

[0072] [Step S105] The compiler 120 adds to the executable file 112 machine language instructions corresponding to the interpreted statements. [Step S106] 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 address of the data, the name of the data corresponding to the address, the data format, and the like, in addition to the changed value of the data to be recorded.

[0073] [Step S107] The compiler 120 determines whether interpretation has been completed up to the last instruction of the program written in the source file 111. If interpretation has been completed up to the last instruction, the compiler 120 ends compilation. If there are any uninterpreted instructions, the compiler 120 proceeds to step S101.

[0074] In this way, compilation is performed by compiler 120, and executable file 112 in which processing is described by machine language instructions is generated. Note that the above explanation shows processing on development machine 100a, which has the same execution environment as the source machine, but compilation is also performed by compiler 150 in development machine 100b, which has the same execution environment as the destination machine, according to the processing procedure shown in Figure 6.

[0075] Figure 7 is a diagram showing an example of compilation. Figure 7 shows an example of compiling a program source file 111 written in the COBOL language. The file name of the source file 111 is "a.cob", and the program written in the source file 111 is "PROG-A". Note that the contents of the executable file 112 do not indicate the machine language instructions themselves, but rather indicate the meaning of the written instructions.

[0076] For example, the compiler 120 generates instructions to record the current value of the data being manipulated before and after every statement that describes a data change. Below, we will explain in detail an example of generating an instruction to record the value of data for the statement "READ FILE-1." (line number "000100") in a program.

[0077] The compiler 120 understands the specifications of the statements in the language. Therefore, by analyzing the statement, the compiler 120 can determine which data the statement may change. In the case of a READ statement (a statement that reads data from a file) in the source file 111 shown in Figure 7, the compiler 120 recognizes the following: A READ statement may overwrite the data area WK-RECORD. From the definition of WK-RECORD, WK-RECORD is composed of the following terminal items. WK-ITEM-1: 4 bytes WK-ITEM-2: 8 bytes The compiler 120 generates instructions to record the values ​​of data areas that may be changed before and after the instruction for the READ statement in this example. This instruction generation is performed for each data area that may be changed. In this example, the only data area that may be changed is WK-RECORD, so the compiler 120 generates an instruction to record the data value only for WK-RECORD. However, instead of generating this instruction for WK-RECORD, the compiler 120 outputs it in order for each terminal data item (in this case, WK-ITEM-1 and WK-ITEM-2).

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

[0079] The "instruction to record a value in a data area" is, for example, a read instruction for a runtime function that has the function of recording the value of the data in data change history 115. In this case, compiler 120 generates an instruction to pass the following information to the runtime function in order to record the value of the data in data change history 115: The position of the statement to be recorded (in the example in Figure 7, line "000100" in "a.cob") Event type (before or after execution of the statement to be recorded) -Start address of data area Data area size Data name (a qualified name that can uniquely identify the data within the running process (e.g., PROG-A / WK-RECORD / WK-ITEM-1)) Data format During translation, the compiler 120 determines the data format of each data area from, for example, the following information: COBOL default values ​​according to the data type (often set for each execution environment) - Specification by COBOL compile options, etc. (for example, the user overwriting the default value) Explicit description of data in source file 111 In this way, an executable file 112 is generated that includes instructions for recording data values. Similarly, an executable file 142 is generated in development machine 100b, which has the destination execution environment. Then, in development machines 100a and 100b, which have the source and destination execution environments, the executable files 112 and 142 are executed, and the data values ​​before and after the change are recorded in data change histories 115 and 145. Then, by comparing the data change histories 115 and 145 for the source and destination execution environments, a comparison result is generated that indicates whether or not there are any incompatible operations.

[0080] 8 is a diagram showing an example of the generation and comparison process of a data change history. For example, in response to an input to development machine 100a instructing execution of executable file 112, execution unit 130 reads machine language program 112a from executable file 112 and executes program 112a. When executing an instruction to record a data value (a runtime function call instruction), execution unit 130 reads the corresponding runtime 114a from runtime library 114. Then, execution unit 130 stores the data value in data change history 115 by executing the instruction written in runtime 114a.

[0081] In response to an input to development machine 100b instructing it to execute executable file 142, execution unit 160 reads machine language program 142a from executable file 142 and executes program 142a. When executing an instruction to record a data value (an instruction to call a runtime function), execution unit 160 reads the corresponding runtime 144a from runtime library 144. Then, execution unit 160 stores the data value in data change history 145 by executing the instruction written in runtime 144a.

[0082] When execution of executable file 112 by execution unit 130 and execution of executable file 142 by execution unit 160 are completed, data history comparison unit 170 compares data change history 115 with data change history 145 and outputs comparison result 171. Comparison result 171 indicates whether or not the operations of the applications provided by executable files 112 and 142 are compatible before and after the migration.

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

[0084] In the data change history 115, the log records are output in order, divided into terminal items (WK-ITEM-1 and WK-ITEM-2 in this case) rather than for the entire data area to be operated on (WK-RECORD in this case).

[0085] A log record includes the following information: a serial number, a source file name, a line number, an event type, an address, a size, a value, a data name, and a data format. The serial number is an identification number assigned to the log record, and is assigned in ascending order starting from 1 in order of earliest recording in the log record. The source file name is the file name of the source file 111 from which the executed executable file 112 was generated. The line number is the line number in the source file 111 where the instruction corresponding to the instruction that caused the log record to be output is written. The event type is information indicating whether the log record is a log before the execution of an instruction that changes data (pre-execution) or after the execution of an instruction that changes data (post-execution). The address is the address in memory of the data to be changed. The size is the number of bytes of the data to be changed. The value is the value of the data before or after the change. The data name is a qualified name that allows the data to be uniquely identified 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.

[0086] In the example of Figure 9, the data format of WK-ITEM-1 is a big-endian binary integer, and the data format of WK-ITEM-2 is a Japanese EUC character string. Data change history 145 generated on development machine 100b having the target environment also contains the same types of information as data change history 115. Log records with the same serial numbers correspond to each other in data change history 115 and data change history 145. Data history comparison unit 170 compares the corresponding log records to determine whether there is compatibility between the processes before and after the migration according to the command statements with the line numbers indicated in the log records.

[0087] 10 is a flowchart showing an example of the procedure for the data change history comparison process. The process shown in FIG. 10 will be explained below in order of step number. <Step S201> The data history comparison unit 170 initializes a variable i, which indicates the serial number of the log record to be compared, to "1".

[0088] [Step S202] The data history comparison unit 170 acquires the i-th log record (serial number i) from each of the data change histories 115 and 145. [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, the data history comparison unit 170 proceeds to step S205. If the data names are different, the data history comparison unit 170 proceeds to step S204.

[0089] [Step S204] The data history comparison unit 170 determines that the programs executed when the data change histories 115 and 145 were generated do not match, and ends the comparison process of the data change histories 115 and 145.

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

[0091] [Step S206] The data history comparison unit 170 determines whether the difference in data format is a difference in floating point. If the difference is a difference in floating point, the data history comparison unit 170 proceeds to step S208. If the difference is something other than a difference in floating point, the data history comparison unit 170 proceeds to step S207.

[0092] [Step S207] The data history comparison unit 170 converts the data format of one piece of data to the data format of the other piece of data. As a result, the data formats of the data in the two log records being compared match. After that, the data history comparison unit 170 proceeds to step S209.

[0093] [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 numbers into numeric format (e.g., a string of numbers and decimal points).

[0094] <Step S209> The data history comparison unit 170 compares the data values ​​indicated in the 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, the data history comparison unit 170 proceeds to step S211. If the data values ​​are different, the data history comparison unit 170 proceeds to step S212.

[0095] [Step S211] The data history comparison unit 170 outputs a comparison result record indicating that compatibility between the operations has been confirmed to the comparison result 171. After that, the data history comparison unit 170 proceeds to step S213.

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

[0097] [Step S214] The data history comparison unit 170 determines whether the i-th log record exists in the data change histories 115, 145. If the i-th log record exists, the data history comparison unit 170 proceeds to step S202. If the i-th log record does not exist, the data history comparison unit 170 ends the data change history comparison process.

[0098] In this way, log records with the same serial number are compared to determine whether there are any incompatible operations due to differences in data format. 11 is a diagram showing a first example of data comparison processing. The 13th log record in the data change history 115 acquired in the source execution environment indicates that WK-ITEM-1 was translated as a binary integer with big endian. The 14th log record in the data change history 115 indicates that WK-ITEM-2 was translated as a Japanese EUC character string.

[0099] The 13th log record in the data change history 145 obtained in the destination execution environment indicates that WK-ITEM-1 was translated as a binary integer with little endian. The 14th log record in the data change history 145 indicates that WK-ITEM-2 was translated as a UTF-16LE string.

[0100] When comparing log records, the data history comparison unit 170 first verifies that the data names match. If the data names do not match, the data history comparison unit 170 determines that the program processing logic is different (the programs are not the same) and stops the comparison. Even if the program logic is the same, the addresses may differ depending on the execution environment, so the addresses indicated in the log records being compared may be different. In the example of Figure 11, the data name of the 13th log record is both "WK-ITEM-1". Furthermore, the data name of the 14th log record is both "WK-ITEM-2". Therefore, the data names match in both cases.

[0101] If the data names match, the data history comparison unit 170 determines whether the data formats match, and if the data formats match, compares the data values ​​without converting the data formats. On the other hand, if the data formats do not match, the data history comparison unit 170 matches the data formats and then compares the data values.

[0102] When comparing the 13th log record, the data history comparison unit 170 changes the endian of the data in the log record in the data change history 115 acquired based on the source execution environment from big endian to little endian. The data history comparison unit 170 then aligns the endian and compares the data values. 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 to the comparison result 171.

[0103] When comparing the 14th log record, the data history comparison unit 170 converts the character code of the data in the log record in the data change history 115 acquired based on the source execution environment to UTF16-LE. Then, the data history comparison unit 170 aligns the character codes and compares the data values. The data value of the 14th log record is already identical before the character code conversion. This occurs, for example, when a data format conversion is omitted when generating the data files 143a, 143b, etc. Converting one of the character codes of the comparison targets that have the same value results in a mismatch. Therefore, the data history comparison unit 170 outputs a comparison result record 171b to the comparison result 171, indicating the detection of an incompatible operation.

[0104] The comparison result 171 stores comparison result records 171a and 171b each time log records are compared. The comparison result records 171a and 171b include a result, a serial number, a source file name, a line, and an event type. The result is information indicating whether or not compatibility is confirmed, and is set to "OK" if compatibility is confirmed, or "NG" if an 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 or 141 corresponding to the executable file 112 or 142 executed to generate the data change history 115 or 145 to be compared. The line is the line number of the command statement in the source file 111 or 141 corresponding to the command that records the compared log record. The event type is information indicating whether the compared log record is a log before the execution of an instruction that changes data (pre-execution) or after the execution of an instruction that changes data (post-execution). The data name is the data name of the data indicated in the compared log record.

[0105] The comparison result records 171a and 171b also include the data format, size, and value of the data in the migration source log record, as well as the data format, size, and value of the data in the migration destination log record.

[0106] For example, the comparison result record 171a indicates that the result is "OK," meaning that compatibility has been confirmed. The comparison result record 171b indicates that the result is "NG," meaning that an incompatible operation has been detected.

[0107] Fig. 12 is a diagram showing a second example of the data comparison process, which shows an example of the comparison process when the floating-point formats are different. The 23rd log record in the data change history 115 obtained in the source execution environment indicates that WK-ITEM-1 was translated as a binary integer with big endian. The 24th log record in the data change history 115 indicates that WK-ITEM-2 was translated as a floating-point number called host format floating.

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

[0109] When comparing the 23rd log record, the data history comparison unit 170 changes the endian of the data in the log record in the data change history 115 acquired based on the source execution environment from big endian to little endian. The data history comparison unit 170 then aligns the endian and compares the data values. 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, which indicates compatibility confirmation, to the comparison result 171.

[0110] When comparing the 24th log record, the data history comparison unit 170 converts the floating-point data of both log records into numeric values. The data history comparison unit 170 then compares the numeric values ​​represented by the data values ​​(floating-point). The numeric 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, which indicates compatibility confirmation, to the comparison result 171.

[0111] For example, the comparison result records 171c and 171d both show a result of "OK," which indicates that compatibility has been confirmed. In this way, if the data formats of the log records to be compared are different, the data history comparison unit 170 unifies the data formats into one of the two data formats or a predetermined data format and then compares the data values. This makes it possible to determine whether the meanings expressed by the data values ​​are the same.

[0112] If the data formats match, the data history comparison unit 170 compares the data values ​​as they are. If the data history comparison unit 170 detects that the data values ​​differ as a result of the comparison, it determines that an incompatible operation has occurred in the destination execution environment, and outputs a comparison result record indicating this to the comparison result 117.

[0113] The comparison result 117 indicates, in the order of the compared log records, whether the comparison confirmed compatibility (OK) or detected an incompatible operation (NG). By displaying the comparison result 171 on the monitor 21, the operator can identify the line in the source files 111, 141 corresponding to the log record in which the incompatible operation was detected earliest. The line in which the incompatible operation was detected earliest is presumed to be the location where the incompatible operation occurred. In other words, by referring to the comparison result 171, the operator can easily identify the location where the incompatible operation occurred.

[0114] Additionally, the compilers 120 and 150 add instructions that record data values ​​before and after instructions that change data, making it easy to check from the comparison results what kind of data conversion was performed at the point where the incompatible behavior occurred, and quickly identifying the cause of the incompatible behavior.

[0115] Other Embodiments In the second embodiment, development machines 100a and 100b are provided in addition to operation machines 200a and 200b, but application compatibility may also be verified using operation machines 200a and 200b.

[0116] In the second embodiment, the compilers 120 and 150 add instructions to record data values ​​before and after instructions that change data, but instructions to record data values ​​may be added by means other than the compilers 120 and 150. For example, the development machines 100a and 100b can analyze the machine language program in an executable file that has already been generated and add instructions to record data values ​​before and after instructions that change data.

[0117] In addition, in the second embodiment, an instruction to record the value of data is added both before and after an instruction that changes the data, but the development machines 100a and 100b may add an instruction to record the value of data only either before or after an instruction that changes the data.

[0118] Although the embodiments have been described above, the configuration of each part shown in the embodiments can be replaced with other parts having similar functions. Also, any other components or processes may be added. Furthermore, any two or more configurations (features) of the above-described embodiments may be combined. [Explanation of symbols]

[0119] 1. Program to be verified 2 First executable program 3 Second executable program 4. First Data 5 Second Data 6 First Data Change History 7 Second Data Change History 10. Information processing equipment 11 Storage section 12 Processing section 12a First Program Execution Environment 12b Second Program Execution Environment

Claims

1. adding a first recording instruction to a first execution program for executing, in a first program execution environment, processing according to a program to be verified that includes an instruction to be verified that modifies a data value, the first recording instruction being for recording a change made by a first data modification instruction set in the first execution program based on the instruction to be verified; by executing the first execution program in the first program execution environment, acquiring a first data change history including a value of the first data before or after the change by the first data change instruction; adding a second recording instruction to a second execution program for executing processing in accordance with the program to be verified in a second program execution environment, the second recording instruction being for recording changes made by a second data modification instruction set in the second execution program based on the instruction to be verified; by executing the second execution program in the second program execution environment, acquiring a second data change history including a value of the second data before or after the change by the second data change instruction; comparing a meaning in the first program execution environment represented by the value of the first data shown in the first data change history with a meaning in the second program execution environment represented by the value of the second data shown in the second data change history, and determining that an incompatible operation has occurred if the meanings are different; A verification program that causes a computer to execute a process.

2. In the acquisition of the first data change history, the first data change history including a first data format required for the first data and a value of the first data before or after the change is acquired; In the acquisition of the second data change history, the second data change history including a second data format required for the second data and a value of the second data before or after the change is acquired; In the process of determining that an incompatible operation has occurred, a data format of at least one of the first data and the second data is converted 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, and values ​​of the first data and the second data are compared. The verification program according to claim 1.

3. adding a first recording instruction to a first execution program for executing, in a first program execution environment, processing according to a program to be verified that includes an instruction to be verified that modifies a data value, the first recording instruction being for recording a change made by a first data modification instruction set in the first execution program based on the instruction to be verified; by executing the first execution program in the first program execution environment, acquiring a first data change history including a first data name identifying first data whose value has been changed by the first data change instruction; adding a second recording instruction to a second execution program for executing processing in accordance with the program to be verified in a second program execution environment, the second recording instruction being for recording changes made by a second data modification instruction set in the second execution program based on the instruction to be verified; executing the second execution program in the second program execution environment to obtain a second data change history including a second data name that identifies second data whose value has been changed by the second data change instruction; detecting an incompatible operation by comparing the first data name indicated in the first data change history with the second data name indicated in the second data change history; A verification program that causes a computer to execute a process.

4. adding a first recording instruction to a first execution program for executing, in a first program execution environment, processing according to a program to be verified that includes an instruction to be verified that modifies a data value, the first recording instruction being for recording a change made by a first data modification instruction set in the first execution program based on the instruction to be verified; by executing the first execution program in the first program execution environment, acquiring a first data change history including a value of the first data before or after the change by the first data change instruction; adding a second recording instruction to a second execution program for executing processing in accordance with the program to be verified in a second program execution environment, the second recording instruction being for recording changes made by a second data modification instruction set in the second execution program based on the instruction to be verified; by executing the second execution program in the second program execution environment, acquiring a second data change history including a value of the second data before or after the change by the second data change instruction; comparing a meaning in the first program execution environment represented by the value of the first data shown in the first data change history with a meaning in the second program execution environment represented by the value of the second data shown in the second data change history, and determining that an incompatible operation has occurred if the meanings are different; A verification method in which processing is performed by a computer.

5. a first recording instruction for recording changes made by a first data modification instruction set in the first execution program based on the verification target instruction, to be added to a first execution program for executing processing in a first program execution environment in accordance with a program to be verified, the first execution program including a verification target instruction that changes a data value; and executing the first execution program in the first program execution environment to obtain a first data modification history including a value of first data before or after the change by the first data modification instruction; and adding a first recording instruction for recording changes made by a first data modification instruction set in the first execution program based on the verification target instruction, to obtain a first data modification history including a value of first data before or after the change by the first data modification instruction, to a second execution program for executing processing in a second program execution environment in accordance with the program to be verified, the first recording instruction for recording changes made by a first data modification instruction set in the first execution program based on the verification target instruction, and executing the first execution program in the first program execution environment to obtain a first data modification history including a value of first data before or after the change by the first data modification instruction, a processing unit that adds a second recording instruction to record changes made by a second data modification instruction set in the execution program of the program, executes the second execution program in the second program execution environment, thereby obtaining a second data modification history including a value of the second data before or after the change made by the second data modification instruction, compares the meaning in the first program execution environment represented by the value of the first data shown in the first data modification history with the meaning in the second program execution environment represented by the value of the second data shown in the second data modification history, and determines that an incompatible operation has occurred if the meanings are different; An information processing device having the above.

Images