WO2016031959A1 - マイグレーション支援装置 - Google Patents

マイグレーション支援装置 Download PDF

Info

Publication number
WO2016031959A1
WO2016031959A1 PCT/JP2015/074401 JP2015074401W WO2016031959A1 WO 2016031959 A1 WO2016031959 A1 WO 2016031959A1 JP 2015074401 W JP2015074401 W JP 2015074401W WO 2016031959 A1 WO2016031959 A1 WO 2016031959A1
Authority
WO
WIPO (PCT)
Prior art keywords
character
program
data
code
width
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2015/074401
Other languages
English (en)
French (fr)
Japanese (ja)
Inventor
孝介 坂井
佳範 城代
厚志 粟河
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Social Information Services Ltd
Original Assignee
Hitachi Government and Public Sector System Engineering Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Government and Public Sector System Engineering Ltd filed Critical Hitachi Government and Public Sector System Engineering Ltd
Priority to CN201580046561.8A priority Critical patent/CN106663020B/zh
Publication of WO2016031959A1 publication Critical patent/WO2016031959A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/12—Use of codes for handling textual entities

Definitions

  • the present invention relates to a technology of so-called legacy migration (hereinafter sometimes simply referred to as “migration”), and more particularly, to a technology of migration that involves switching character code systems.
  • a predetermined character code system e.g., EBCDIK (Extended Binary Coded Decimal Interchange Kana Code), KEIS (Kanji processing Extended Information System), JIS8, SJIS (Shift JIS), hereinafter referred to as “old character code system”.
  • the host computer that handles the data has registered many external characters that are not registered as standard in the character code system (the external character area of the host computer is 9024 characters). In this case, migration to a server computer running an OS that can provide only a small external character area (the external character area provided by WINDOWS is equivalent to 1880 characters) cannot be realized.
  • Migration mainly involves (1) migration of existing data on the business system, and (2) migration of existing programs operating on the business system that access such data. Therefore, it is necessary to convert the character code of the existing character data to be migrated so as to correspond to the new character code system.
  • An existing program for example, a program written in the COBOL language
  • An existing program needs to be converted so that character data obtained by converting the character code can be read.
  • the conventional technique has a problem that the conversion of the program is very complicated and difficult as compared with the conversion of the character code assigned to the character data.
  • the problem is that depending on the combination of the old character code system and the new character code system, the number of bytes in the byte string representing that character may differ between the two character code systems, even for the same character. This is due to the fact that the length of the area in memory that the program specifies to store the byte sequence of characters is a fixed length.
  • it is necessary to modify the contents of the program as appropriate in consideration of these circumstances. Will get different character data).
  • the correction pattern differs depending on the byte string of characters stored in the area, the correction is a very complicated and difficult task. In the prior art including the technique of Patent Document 1, there is no improvement measure for such work.
  • an object of the present invention is to facilitate the conversion of a program to be migrated in migration involving switching to a different character code system.
  • the present invention provides: A migration support apparatus that supports migration from a first computer to a second computer,
  • the second character of the second computer has the first character code assigned to the character data in the first document file of the first computer with reference to the character code conversion table of the storage unit.
  • a character code conversion unit that converts the second character code assigned to the character data in the document file;
  • the first program for processing the first document file included in the first computer is converted into the second program for processing the second document file included in the second computer.
  • a program conversion unit for By causing the second program to read the character data to which the second character code is assigned, the number of areas on the memory designated by the second program for the read character data is set to the character
  • An exchange information generating unit for generating exchange information determined to be the same as the number of bytes of the byte string expressing the first character code assigned to the data;
  • An area storage unit for storing one of the second character codes assigned to the read character data in the area having a number determined by the exchange information; It is characterized by that. Other means will be described later.
  • the first legacy program treats the size of the character data (item length) as the number of bytes in the byte sequence, specifies the same number of bytes as the number of bytes on the memory, and stores the byte sequence of the character data. It was. That is, as in the prior art, the first program uses the area specified on the memory as an area for storing 1-byte data, and processes character data in units of bytes. Further, the description contents of the source code of the first program correspond to the processing. On the other hand, the converted second program refers to the exchange information when processing the character data in which the number of bytes of the byte string representing one character is different by converting the character code. As many areas as can be used.
  • the second program can process the character data in units of the number of characters by setting the area designated on the memory as one or a plurality of areas for storing data of one character. Therefore, the logic assembled in the second program can be made the same as the logic assembled in the first program, and the portion related to the logic (for example, COBOL language) in the description contents of the source code of the second program There is no need to correct the number of digits in. Therefore, in a migration that involves switching to a different character code system, it is possible to easily convert a program to be migrated.
  • FIG. 7 is a diagram for explaining that, when a COBOL language program is converted in accordance with the conversion from the EBCDIK + KEIS code to the UTF-8 code, modification of the description content of the source code is not necessary, ) Is a diagram showing a description example of the data section working section in the source code of the pre-conversion program and a schematic diagram of an area embodying the description example, and (b) is a source code of the post-conversion program 2 is a schematic diagram of an area embodying a description example of a data section working section and a description example in which a predetermined correction is unnecessary.
  • the work PC 1 is a computer operated by a worker in charge of migration from the current computer 2 to the new computer 3, and is a migration support apparatus of this embodiment.
  • the work PC 1 acquires the input file 21 and the input program 22 from the current computer 2, performs predetermined conversion (details will be described later), and then outputs the output file 31 and the output program 32 to the new computer 3.
  • the current computer 2 (first computer) is a general-purpose host computer.
  • the new computer 3 (second computer) is an open server computer.
  • the input file 21 (first document file) is a document file including character data and is a legacy of the current computer 2.
  • the character data in the input file 21 follows the character code system handled by the current computer 2.
  • the character code system handled by the current computer 2 is EBCDIC for character data of half-width alphanumeric characters, half-width symbols, and half-width kana characters, and KEIS for character data of full-width characters.
  • the character code assigned to the character data in the input file 21 may be referred to as “EBCDIK + KEIS code”.
  • the input program 22 (first program) is a program for processing the input file 21, and is a legacy of the current computer 2.
  • the input program 22 is described in the COBOL language, and the description content conforms to a character code system composed of EBCDIC and KEIS.
  • the output file 31 (second document file) is a document file including character data.
  • the character data in the output file 31 follows the character code system handled by the new computer 3.
  • the character code system handled by the new computer 3 is UTF-8 for character data of any one-byte alphanumeric characters, half-width symbols, half-width kana characters, and full-width characters.
  • the character code assigned to the character data in the output file 31 may be referred to as “UTF-8 code”.
  • the output program 32 (second program) is a program for processing the output file 31.
  • the output program 32 is described in the COBOL language.
  • the output program 32 can be described in JAVA (registered trademark) language.
  • the work PC 1 includes hardware such as an input unit, an output unit, a control unit, and a storage unit.
  • the control unit is constituted by a CPU (Central Processing Unit)
  • information processing by a computer including the control unit is realized by program execution processing by the CPU.
  • the storage unit included in the computer stores a program that is instructed by the CPU and implements the function of the computer. This realizes cooperation between software and hardware.
  • the program is provided by being recorded on a recording medium or via a network.
  • the work PC 1 has functional units such as a character code conversion unit 11, a program conversion unit 12, an exchange information generation unit 13, and an area storage unit 14, and includes a character code conversion table T, Exchange information E is stored in the storage unit.
  • the character code conversion unit 11 assigns the EBCDIC + KEIS code (first character code) assigned to the character data in the input file 21 to the character data in the output file 31 with reference to the character code conversion table T. Convert to UTF-8 code (second character code).
  • the program conversion unit 12 converts the input program 22 into the output program 32 so as to correspond to the character code conversion by the character code conversion unit 11.
  • the program conversion unit 12 can convert the description language of the output program 32 to be the same as the description language of the input program 22 (for example, COBOL ⁇ COBOL), or can convert it differently (for example, : COBOL ⁇ JAVA).
  • the exchange information generation unit 13 causes the output program 32 to read the character data to which the UTF-8 code has been assigned, so that the number of areas on the memory designated by the output program 32 is determined for the read character data.
  • the exchange information E defined to be the same as the number of bytes of the byte string expressing the EBCDIC + KEIS code assigned to is generated.
  • the character data assigned with the UTF-8 code read by the output program 32 is, for example, character data extracted from the output file 31.
  • the area storage unit 14 stores one UTF-8 code assigned to the character data read by the output program 32 in the area having the number determined by the exchange information E.
  • the character code conversion table T is assigned to a character included in a predetermined character set (for example, a character set of characters defined by the character code system composed of EBCDIK and KEIS handled by the current computer 2).
  • a predetermined character set for example, a character set of characters defined by the character code system composed of EBCDIK and KEIS handled by the current computer 2.
  • the EBCDIK + KEIS code and the UTF-8 code are associated with each other. The details of the association are well known and will not be described.
  • the exchange information E generated by the exchange information generation unit 13 includes, for each character data to which the UTF-8 code is assigned, the number of bytes that is the size of the character data (the length of the item), and a memory designated by the output program 32 Corresponds to the number of upper areas.
  • UTF-8 codes assigned to various character data are character codes that represent half-width alphanumeric characters (half-width alphanumeric characters + half-width symbols), character codes that represent half-width kana characters, full-width characters. It can be classified into character codes representing characters. The “number of bytes” and “number of areas” described above are determined for the classified character codes.
  • UTF-8 expresses one corresponding character by 1 byte, so the “number of bytes” is “1”.
  • EBCDIC expresses one character in one byte for one-byte alphanumeric characters and one-byte symbols, and therefore, the number of areas becomes “1” by the function of the exchange information generation unit 13.
  • UTF-8 represents the corresponding character in 3 bytes, so the “number of bytes” is “3”.
  • EBCDIC expresses one character in one byte for half-width kana, and “number of areas” becomes “1” by the function of the exchange information generation unit 13.
  • UTF-8 represents the corresponding character in 3 bytes, so the “byte count” is “3”.
  • KEIS expresses one character with 2 bytes for double-byte characters, so that the number of areas becomes “2” by the function of the exchange information generation unit 13.
  • the content of the exchange information E is determined by the combination of the character code system handled by the current computer 2 and the character code system handled by the new computer 3.
  • step S1 the work PC 1 acquires the input file 21 and the input program 22 from the current computer 2. After step S1, the process proceeds to step S2.
  • step S ⁇ b> 2 the work PC 1 converts the character code of the acquired character data in the input file 21 from the EBCDIK + KEIS code to the UTF-8 code by the character code conversion unit 11 to generate the output file 31. .
  • step S2 the process proceeds to step S3.
  • step S ⁇ b> 3 the work PC 1 converts the acquired input program 22 into the output program 32 by the program conversion unit 12. After step S3, the process proceeds to step S4.
  • step S4 the work PC 1 reads the character data to which the UTF-8 code is assigned by the output program 32. After step S4, the process proceeds to step S5.
  • step S5 the work PC 1 uses the exchange information generation unit 13 to generate exchange information E for the character data read in step S4. After step S5, the process proceeds to step S6.
  • step S6 the work PC 1 uses the area storage unit 14 to store the UTF-8 code corresponding to the area (the area on the memory designated by the output program 32) of the number determined by the exchange information E, that is, in step S4.
  • the UTF-8 code assigned to the character data read in is stored.
  • the output file 31, the output program 32, and the exchange information E generated by the work PC 1 are output to the new computer 3.
  • the output program 32 opens the output file 31 in order to execute a predetermined business process in the new computer 3.
  • the output program 32 refers to the exchange information E and accesses the UTF-8 code stored in the memory area designated by the output program 32 in the order determined by the output program 32.
  • the input program 22 treats the size of the character data (item length) in the input file 21 as the number of bytes of the byte sequence, specifies the same number of areas as the number of bytes on the memory, and stores the byte sequence of the character data. Was. In other words, as in the past, in the current computer 2, the input program 22 uses the area specified on the memory as an area for storing 1-byte data, and character data in the input file 21 in units of bytes. By processing, the character data is processed in order substantially one character at a time.
  • the exchange information E inputs the number of areas specified by the output program 32 on the memory.
  • the program 22 can be the same as the number of areas designated on the memory.
  • the output program 32 converts the exchange information E to the full-width character data in which the number of bytes in the byte sequence is changed from “2” to “3”.
  • the number of areas designated on the memory can be set to “2” instead of “3” as in the prior art.
  • the area storage unit 14 stores one UTF-8 code assigned to the full-width character in two (continuous) areas.
  • the output program 32 can make the area designated on the memory not an area for storing 1-byte data but an area for storing 1-character data, and the output file 31 in units of the number of characters.
  • the character data inside can be processed.
  • the output program 32 outputs the character data in the output file 31 one character at a time. Can be processed. That is, even if migration is performed that involves conversion of character codes having different character data sizes, the logic assembled in the output program 32 can remain the same as the logic assembled in the input file 21. The worker who performs the migration does not need to correct the logic-related part of the description contents of the source code of the output program 32.
  • the work PC 1 stores an area (one byte of data) of a specified number of bytes (for example, three full-width characters) for storing byte sequences of character data to which a UTF-8 code is assigned one byte at a time.
  • the output program 32 can be controlled so as to be separately designated on the memory. Then, the work PC 1 performs control so that the area storage unit 14 associates one or two areas for storing one UTF-8 code with the predetermined number of areas. Therefore, in the new computer 2, when the output program 32 accesses the UTF-8 code stored in the area storage unit 14, the target program is accessed by accessing the byte string stored in the associated area. Can be processed.
  • FIG. 4 shows a comparative example as a conventional technique.
  • the upper part of FIG. 4A shows a description example of the data section working section in the source code of the pre-conversion program.
  • variables (items) DATA-A1 and DATA-A2 are declared in this order.
  • DATA-A1 “PIC X” indicates that one byte of data (EBCDIK) storage area is secured in memory, and “(03)” indicates that there are three such areas. (Number of digits is 3). Therefore, data for 3 characters (half-width characters) can be input to DATA-A1.
  • PIC N indicates that one character 2 bytes of data (KEIS) storage area is secured on the memory, and “(03)” indicates that there are three such areas. (Number of digits is 3). Therefore, data of 3 characters (double-byte characters) can be input to DATA-A2.
  • the COBOL language declares variables with a fixed length.
  • 4A shows a schematic diagram of an area that embodies the above description example. If one area is represented by one box, this box represents a 1-byte data storage area.
  • the pre-conversion program can input data for 3 characters into DATA-A1 by designating an area for 3 bytes on the memory for DATA-A1.
  • the pre-conversion program specifies the area where the byte string of character data is stored for each byte, and processes the character data in units of bytes (in the box in order from the left).
  • FIG. 4B a description example of the data section working section in the source code of the converted program is shown.
  • the description example of FIG. 4A In order to make the logic the same before and after the conversion of the program, it is necessary to modify the description example of FIG. 4A by adding a description as indicated by the underlined portion in the figure.
  • the number of digits is changed from 3 to 9 for DATA-A1.
  • the reason for changing the number of digits in this way is that EBCDIK expresses one half-width kana character in 1 byte, whereas UTF-8 expresses one half-width kana character in 3 bytes.
  • DATA-A1 has an area of 9 bytes (3 bytes ⁇ 3 characters) so that it can cope with a case where a byte string of characters is input (to prevent data overflow).
  • the number of digits is changed from 3 to 5 for DATA-A2.
  • the reason for changing the number of digits in this way is that KEIS expresses one full-width character in 2 bytes, whereas UTF-8 expresses one full-width character in 3 bytes.
  • DATA-A2 is provided with an area of at least 9 bytes (3 bytes ⁇ 3 characters) so as to cope with the case where a character byte string is input.
  • DATA-A2 has an area of 10 bytes.
  • FIG. 4 (b) a schematic diagram of an area embodying the description example with the above modifications is shown.
  • the box shown in FIG. 4B represents a 1-byte data storage area, like the box shown in FIG.
  • the characteristics of the pre-conversion program that data of 3 characters can be input to DATA-A1 and data of 3 characters can be input to DATA-A2 by increasing the number of boxes are converted. It is retained in the program.
  • modifying the logic built into the program so as to increase such boxes requires a large amount of work because it needs to be performed for all variables in the program.
  • FIG. 5 shows this embodiment.
  • FIG. 5A is the same as FIG. That is, data for three characters can be input to the variable DATA-A1, and data for three characters can be input to the variable DATA-A2.
  • FIG. 5B In the upper part of FIG. 5B, a description example of the data section working section in the source code of the converted program is shown.
  • the exchange information E already described is used.
  • the area specified by the converted program on the memory by the exchange information E functions as an area for storing 1-character data, not an area for storing 1-byte data.
  • one box represents one area as a data storage area for one half-width alphanumeric symbol Kana character as shown in the lower part of FIG. 5B.
  • the term “single-byte alphanumeric symbol kana characters” is a word that is a collection of single-byte alphanumeric characters, half-width symbols, and half-width kana characters.
  • a data storage area for one half-width alphanumeric symbol kana character can represent a data storage area for one full-width character when arranged in two.
  • PIC N (03) in DATA-A2 can indicate that three double-byte character (UTF-8) data storage areas are secured in the memory. This means that even if the number of digits is not increased as shown in FIG. 4B (the logic is not modified), the variable DATA-A2 has three characters of data (characters assigned with UTF-8 code). Data).
  • one UTF-8 code is stored in the data storage area of one or two single-byte alphanumeric symbols and one kana character. Therefore, when executing a predetermined job process, the converted program can process character data in units of the number of characters by accessing the UTF-8 code stored in the area in a predetermined order.
  • the converted output program 32 refers to the exchange information E when processing character data in which the number of bytes in a byte string representing one character is different by converting character codes.
  • the same number of areas as the number of areas used by the program 32 can be used. That is, the output program 32 can process the character data in units of the number of characters, with the area designated on the memory being one or a plurality of areas for storing one character data. Therefore, the logic assembled in the output program 32 can be made the same as the logic assembled in the input program 32, and it is not necessary to modify the logic-related part of the description contents of the source code of the output program 32. Therefore, in a migration that involves switching to a different character code system, it is possible to easily convert a program to be migrated.
  • the migration accompanied by the switching from the character code system using EBCDIK and KEIS to the character code system using UTF-8 has been described.
  • the present invention can also be applied to migration involving switching from a character code system using JIS8 and SJIS to a character code system using UTF-8.
  • the area storage unit 14 stores the UTF-8 code in an area on the memory designated by the output program 32.
  • the output program 32 it is also possible to store data in any format that can identify the corresponding character data instead of the UTF-8 code.
  • the exchange information generating unit 13 when the exchange information generating unit 13 generates the exchange information E, the character data assigned with the UTF-8 code read by the output program 32 is, for example, the character data extracted from the output file 31. did. However, for example, the work PC 1 replaces all characters included in a predetermined character set (for example, in the case of migration to an open server computer that handles UTF-8, a character set consisting of all existing characters).
  • a predetermined character set for example, in the case of migration to an open server computer that handles UTF-8, a character set consisting of all existing characters.
  • character data to which a UTF-8 code is assigned may be acquired in advance from the outside, and the acquired character data may be read into the output program 32.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Artificial Intelligence (AREA)
  • Stored Programmes (AREA)
  • Devices For Executing Special Programs (AREA)
  • Document Processing Apparatus (AREA)
PCT/JP2015/074401 2014-08-29 2015-08-28 マイグレーション支援装置 Ceased WO2016031959A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201580046561.8A CN106663020B (zh) 2014-08-29 2015-08-28 迁移支持装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2014-174745 2014-08-29
JP2014174745A JP6491438B2 (ja) 2014-08-29 2014-08-29 マイグレーション支援装置

Publications (1)

Publication Number Publication Date
WO2016031959A1 true WO2016031959A1 (ja) 2016-03-03

Family

ID=55399842

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/074401 Ceased WO2016031959A1 (ja) 2014-08-29 2015-08-28 マイグレーション支援装置

Country Status (3)

Country Link
JP (1) JP6491438B2 (https=)
CN (1) CN106663020B (https=)
WO (1) WO2016031959A1 (https=)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6720993B2 (ja) * 2018-03-07 2020-07-08 オムロン株式会社 サポート装置およびサポートプログラム
CN117270961B (zh) * 2023-11-21 2024-04-12 武汉蜂鸟龙腾软件有限公司 一种Linux环境下MFC字符资源的解析和加载方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06348453A (ja) * 1993-06-11 1994-12-22 Nec Corp データコンバージョンプログラム自動生成方式
JP2008226010A (ja) * 2007-03-14 2008-09-25 Hitachi Ltd コンパイル方法及びコンパイル装置
JP2010224656A (ja) * 2009-03-19 2010-10-07 Ns Solutions Corp ソースコード生成装置、プログラム及びソースコード生成方法

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR900700973A (ko) * 1987-12-11 1990-08-17 시우 창 로 문자인식장치
US5309358A (en) * 1992-02-18 1994-05-03 International Business Machines Corporation Method for interchange code conversion of multi-byte character string characters
JPH11203279A (ja) * 1998-01-19 1999-07-30 Toshiba Corp かな漢字変換装置、かな漢字変換方法、及び記憶媒体
JP4136066B2 (ja) * 1998-05-11 2008-08-20 パイオニア株式会社 文書データ作成装置及び文字表示装置
JP2000105765A (ja) * 1998-09-28 2000-04-11 Toshiba Corp データ変換装置
JP4776050B2 (ja) * 1999-07-13 2011-09-21 ソニー株式会社 配信コンテンツ生成方法、コンテンツ配信方法および装置、並びに、コード変換方法
JP3917343B2 (ja) * 2000-02-25 2007-05-23 株式会社東芝 マルチプラットフォーム環境における文字コード変換方式および文字コード変換プログラムを記録したコンピュータ読み取り可能な記録媒体
CN101079023B (zh) * 2003-01-24 2012-03-21 株式会社理光 字符串处理装置、字符串处理方法和成像装置
JP4072691B2 (ja) * 2004-07-15 2008-04-09 ソニー株式会社 文字情報変換装置および文字情報変換方法
JP4890551B2 (ja) * 2006-08-10 2012-03-07 シャープ株式会社 文字変換装置、文字変換装置の制御方法
EP2869210A4 (en) * 2012-06-29 2016-05-18 Skk Ltd DOCUMENT PROCESSING SYSTEM, ELECTRONIC DOCUMENT, DOCUMENT PROCESSING PROCESS AND PROGRAM

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06348453A (ja) * 1993-06-11 1994-12-22 Nec Corp データコンバージョンプログラム自動生成方式
JP2008226010A (ja) * 2007-03-14 2008-09-25 Hitachi Ltd コンパイル方法及びコンパイル装置
JP2010224656A (ja) * 2009-03-19 2010-10-07 Ns Solutions Corp ソースコード生成装置、プログラム及びソースコード生成方法

Also Published As

Publication number Publication date
JP2016051235A (ja) 2016-04-11
CN106663020B (zh) 2020-05-01
CN106663020A (zh) 2017-05-10
JP6491438B2 (ja) 2019-03-27

Similar Documents

Publication Publication Date Title
CN102741811A (zh) 改善基于模板的JavaScript小部件的性能
JP6491438B2 (ja) マイグレーション支援装置
CN104536769A (zh) 一种国际化文档实现方法
EP1717719A1 (en) Application conversion of source data
US9880612B2 (en) Execution control method and execution control apparatus
US10331465B2 (en) Apparatus and method for realizing runtime system for programming language
JP2011154495A (ja) 文字コード変換装置、文字コード変換方法、および文字コード変換プログラム
US11372742B1 (en) Mining software specification from online documentation
CN111279350B (zh) 用于在服务管理应用接口中提供全球化特征的系统和方法
HK1234839A1 (en) Migration support device
JP2018037031A (ja) データ移行プログラム作成システム及びデータ移行プログラム作成用プログラム
HK1234839B (zh) 迁移支持装置
JP6397343B2 (ja) 情報処理装置、および、情報処理方法
JP7670882B1 (ja) 情報処理装置、情報処理方法、プログラム、および、コンピュータ可読記憶媒体
US9792197B2 (en) Apparatus and program
JP2010282248A (ja) プログラム言語解析実行プログラム
Horton Basic Ideas
JP2010224656A (ja) ソースコード生成装置、プログラム及びソースコード生成方法
Motamedisedeh Leveraging Scripting and External Integrations in Power Query
JP2024119527A (ja) 計算機およびプログラム
Sharan Character Encodings
Feiler Looking Inside a Document
HK40030448A (en) Systems and methods for providing globalization features in a service management application interface
Parkin Number Input
Sutherland Chapter 3: Working with Text

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15835972

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15835972

Country of ref document: EP

Kind code of ref document: A1