JP4319706B2 - Program development support tool - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a support tool in program development using IDL (interface definition language).
[0002]
[Prior art]
In computer program development, a program (or data) may be created in units of functional blocks. According to this method, the program development efficiency can be improved and the program can be reused. However, when the target process is realized by linking a plurality of program processes, it is necessary to previously define an interface such as a calling rule between the programs. IDL (interface definition language) may be used for the definition of this interface.
[0003]
As IDL, IDL used in CORBA (Common Object Request Broker Architecture) proposed by OMG (Object Management Group) is known. As a reference for the language mapping specification of CORBA, there is “The Common Object Request Broker: Architecture and Specification Revision 2.0, Julie 1995 Updated Jul 1996” published by OMG. Also, as a reference for general background on CORBA, there is “Distributed Object Oriented Technology CORBA” published by Hirofumi Onozawa, Soft Research Center.
[0004]
CORBA defines IDL, mapping specifications between various program languages and IDL, and ORB (object request broker) for managing communication between programs. The developer describes the interface of each program in IDL according to the mapping specification. By compiling this IDL source with a dedicated compiler (IDL compiler), a stub for a client program and a skeleton for a server program are generated. Here, the stub and the skeleton are subprograms for mediating between the client program and the server program and the ORB.
[0005]
Such program development using IDL further has the advantage that it is easy to use programs written in different languages and programs executed on computers having different architectures.
[0006]
Hereinafter, processing systems that generate stubs and skeletons from an IDL source, such as a CORBA IDL compiler, are collectively referred to as an IDL language processing system. A processing system that generates an IDL source from an existing program is generically called an IDL generation system. The IDL generation system is effective when an existing program is diverted and processing linked to another program is performed.
[0007]
FIG. 8 shows an example of a functional configuration of a conventional IDL language processing system.
[0008]
The IDL syntax analysis unit 102 receives the IDL source 101 as input, performs IDL syntax analysis, and outputs analysis information 103. Here, the analysis information 103 includes IDL information that defines calling rules between programs, such as procedure and method names, argument data types, and sequences.
[0009]
The code generation unit 104 includes an interface information analysis unit 105, a program code generation unit 106, and a type conversion table 109. In the type conversion table 109, the data type information of IDL included in the analysis information 103 and the data type incorporated in the program code 108 are stored in association with each other. The interface information analysis unit 105 refers to the type conversion table 109 and converts the IDL data type information in the analysis information 103 into a data type used in a stub or skeleton. Using this conversion result, the program code generation unit 106 generates a stub 107 and a skeleton 108.
[0010]
FIG. 9 shows an example of a functional configuration of a conventional IDL generation system.
[0011]
The syntax analysis unit 202 analyzes the source program 201 and generates analysis information 203. The interface information extraction unit 204 extracts interface information such as procedure and method names, argument data types, and arrangements from the analysis information 203 and outputs them as an intermediate language 205. In the type conversion table 206 in the IDL generation system, data type information included in the intermediate language 205 and data type information used in IDL are stored in association with each other. The code generation unit 207 refers to the type conversion table 206 and converts the data type information in the intermediate language 205 into data type information used in the IDL source. Using this conversion result, the IDL output unit 211 generates the IDL source 212 so as to satisfy the IDL grammar.
[0012]
In general, when data is exchanged between programs written in different languages, the data type needs to be a type that can be used in common in both program languages. For this reason, the above-described IDL language processing system and IDL generation system can process only data types that can be commonly used in a plurality of target program languages (for example, C language, C ++ language, etc.).
[0013]
[Problems to be solved by the invention]
The above-described conventional IDL language processing system and IDL generation system cannot process data types that cannot be used in common in a plurality of target programming languages, and therefore cannot properly generate stubs, skeletons, and IDL sources depending on application programs. There is.
[0014]
For this reason, for example, when a data type that cannot be processed by the IDL generation system is specified in an existing application program to be diverted, the developer may modify the interface specification of the diverted program or It has been necessary to perform complicated manual work such as creating a wrapper function that performs the function of making changes.
[0015]
Therefore, an object of the present invention is to provide a program development support tool capable of generating a subprogram that realizes an interface function of a program without limitation of a data type used in the program described in the target programming language. It is to provide.
[0016]
Another object of the present invention is to provide a program development support tool capable of generating IDL source information that can be processed by the program development support tool for an arbitrary program described in a target program language. There is.
[0017]
[Means for Solving the Problems]
In order to solve the above problems, the present invention generates a subprogram (for example, a stub or a skeleton) that realizes an interface function of the program based on IDL source information that describes a calling rule between a plurality of programs. In the program development support tool, the type information of the data type used in the programming language describing the program and the type definition information that describes the data type according to a predetermined rule are registered in association with each other. A type conversion table having a special table, means for extracting type definition information described according to the predetermined rule from the IDL source information, and using the type conversion table, the extracted type definition information, Converting into type information of the programming language and registering the type information as code generation information When, using the code generation information, to provide a program development support tool, characterized in that it comprises means for generating the subprograms.
[0018]
The present invention also provides data type information used in a program language for describing the program in a program development support tool for generating IDL source information describing the calling rules of the program based on the source code of the program. And type definition information in which the data type is described according to a predetermined rule, a type conversion table having a special table registered in advance, and type information of data passed by the program , Means for converting type information registered in the special table into type definition information using the type conversion table, and registering the type definition information as code generation information; and a source of the IDL from the code generation information A program development support tool comprising means for generating information is provided.
[0019]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, a program development support tool according to an embodiment of the present invention will be described with reference to the drawings.
[0020]
The program development support tool of this embodiment is for supporting program development in an environment in which a plurality of application programs (client program and server program) operate in cooperation. The function of the program development support tool is divided into an IDL language processing system that generates stubs and skeletons from IDL sources, and an IDL generation system that generates IDL sources from existing programs.
[0021]
FIG. 1 shows a configuration of a computer 1 on which a program development support tool is mounted. As shown, the computer 1 includes a processor 2, a RAM 3, a ROM 4, a display 5, a keyboard 6, a mouse 7, an internal disk device 8, an external disk device 9, and various interface circuits (I / F) 10-15. Have. Here, for example, a hard disk device is used as the internal disk device, and for example, a CD-ROM reader or a floppy disk device is used as the external disk device. The communication interface circuit 15 is connected to the network 16 and exchanges files (programs, etc.) with other computers.
[0022]
The function of the program development support tool is realized as a program stored in a recording medium of the external disk device 8 and executed by the processor 2.
[0023]
In the present embodiment, the COBOL language is targeted as the application program creation language. In the COBOL language, the definition of the data type of an argument of an external program can be described using the number of digits when the numerical value is expressed in decimal, the decimal point position, and the usage. For example, the declaration statement 501 in FIG. 2 defines a numerical value in the PACKED decimal format having an integer part of 4 digits and a decimal part of 3 digits. Such a data type may be used in the definition of an argument when called from an external program. However, this data type cannot be described by CORBA IDL. For this reason, conventionally, it has been necessary for a developer to perform troublesome work such as correction of interface specifications.
[0024]
In this embodiment, the COBOL language data type that matches the data type supported by the CORBA IDL is described as before, and the unsupported COBOL language data type is one of the IDL syntax elements. A new description rule (hereinafter referred to as a new description rule) is used. In the CORBA IDL grammar, the type definition name in the TYPEDEF syntax can be freely set by the developer.
[0025]
In the new description rule, a COBOL language data type that is not defined by the CORBA IDL is defined by the predetermined IDL type information and the type definition name in the TYPEDEF syntax. For example, the variable “ARG” of the declaration statement 501 in FIG. 2 is defined by IDL type information “unsigned long” 600 and a type definition name “CBL_PACK_9_4V9_3” 605 as shown in FIG.
[0026]
The type definition name 605 is also described according to the new description rule. Specifically, first, a character string “CBL_” 601 indicating that the description language is the COBOL language is described. Subsequently, a character string 602 corresponding to the application is described. In the example of FIG. 3A, “PACK_” 602 corresponding to “PACKED-DECIMAL” is described. “BIN_” is described for the usage “BINARY”, and “DISP” is described for “DISPLAY”. Subsequently, if necessary, “S” (not shown) indicating a sign is described, and subsequently “9_” 603 indicating a numerical value is described. Subsequently, the number of digits of the integer part of the decimal number (“4” in the example in the figure) is described, and if necessary, the number of digits of the decimal part (“3”) is described following “V9_” (604). .
[0027]
In this way, data types that are not supported by CORBA IDL are described. The IDL language processing system and IDL generation system of the present embodiment described below have a function for dealing with the above-described new description rule.
[0028]
FIG. 4 shows a functional configuration of the IDL language processing system (hereinafter referred to as IDL compiler) of the present embodiment.
[0029]
The illustrated IDL compiler 700 includes a syntax analysis unit 702 and a code generation unit 704. The syntax analysis unit 702 and the code generation unit 704 are functions realized by executing a program in the storage area of the disk devices 8 and 9 of the computer 1.
[0030]
The IDL compiler 700 receives the IDL source 701 and outputs a stub 707 and a skeleton 708 described in the COBOL language. Also, analysis information 703 and code generation information 712 are generated in this processing process.
[0031]
Here, the IDL source 701 is information in which the interface of the target server program is described in IDL according to the new description rule. The IDL source 701, analysis information 703, code generation information 712, stub 707, and skeleton 708 are stored as files in the disk device of the computer 1.
[0032]
The IDL compiler 700 is incorporated in the COBOL dependency information analysis unit 751 incorporated in the syntax analysis unit 702, the COBOL type information conversion unit 752 incorporated in the code generation unit 704, and the type conversion table 709 in order to cope with the new description rule. And a special table 711.
[0033]
As shown in FIG. 5, in the special table 711 of the type conversion table 709, the type definition name (605) described by the new description rule and the COBOL language type information are registered in advance in association with each other. In the standard table 710 of the type conversion table 709, IDL type information and COBOL language type information are registered in advance in association with each other. As a result, all type information in the COBOL language is registered in the type conversion table 709.
[0034]
Note that the type conversion table 709 is arranged in the program of the IDL compiler 700 in order to speed up access. Of course, it may be stored as a file in the disk device of the computer 1.
[0035]
Next, the processing of the IDL compiler 700 will be described with reference to FIG.
[0036]
When a command for instructing compilation of the IDL source 701 is input to the computer 1, the processing of the IDL compiler 700 is started. First, the syntax analysis unit 702 performs syntax analysis of the IDL source 701 to generate analysis information 703. The definition of the data type supported by IDL is processed in the same manner as in the past and is incorporated in the analysis information 703.
[0037]
At this time, as shown in FIG. 5, the COBOL dependency information analysis unit 751 checks the TYPEDEF syntax described in the IDL source 701 and if there is a type definition name (605) having “CBL_” at the head, The type definition name is extracted as type information for COBOL and incorporated into the analysis information 703 (S101, S102). For example, when there is a TYPEDEF syntax shown in FIG. 3A, “CBL_PACK_9_4V9_3” 605 is extracted and incorporated into the analysis information 703 as COBOL type information.
[0038]
Since only the type definition information described in the new description rule is extracted by the COBOL dependency information analysis unit 751, even if other information not related to the new description rule is included in the TYPEDEF syntax, There is no error.
[0039]
The syntax analysis unit 702 performs a grammar check of the IDL source 701. In this embodiment, data types that are not supported by IDL are defined using the TYPEDEF syntax, so that no error occurs in the grammar check.
[0040]
Subsequently, the code generation unit 704 reads the analysis information 703, performs processing for converting IDL type information into COBOL type information, and generates a stub 707 and a skeleton 708.
[0041]
At this time, the interface information analysis unit 705 refers to the standard table 710 of the type conversion table 709 and converts the IDL type information included in the analysis information 703 into the COBOL language type information. This conversion result is registered as code generation information 712. In parallel with this, the COBOL type information conversion unit 752 refers to the special table 711 of the type conversion table 709 and converts the COBOL type information included in the analysis information 703 into COBOL language type information.
[0042]
Specifically, the COBOL type information conversion unit 752 reads the COBOL type information included in the analysis information 703 (S103), and corresponds to the type information in the special table 711 of the type conversion table 709. Is acquired (S104). Then, a parameter is set in the acquired type information, and the result is registered as code generation information 712 (S105).
[0043]
For example, when the information read from the analysis information 703 is “CBL_PACK_9_4V9_3”, “pic 9 (x) v9 (y) PACKED− registered in the non-corresponding conversion table 711 corresponding to“ CBL_PACK_9_xV9_y ”. “DECIMAL” is acquired, and “3” and “4” are set in the parameters x and y, respectively.
[0044]
The program code generation unit 706 uses the code generation information 712 to generate a stub 707 and a skeleton 708 described in the COBOL language.
[0045]
The stub 707 and the skeleton 708 have a PROGRAM-ID statement in which a method name set for itself is defined, and a CALL statement in which the name of a program (method) to be called is defined. The CALL statement in the stub 707 calls an ORB function, and the CALL statement in the skeleton 708 is for calling a server program.
[0046]
The stub 707 and the separately created client program are compiled and linked to COBOL in the computer to be executed to become an executable program. Similarly, the skeleton 708 and the server program are compiled into COBOL and linked in the computer to be executed to become executable programs.
[0047]
The IDL compiler 700 has a mode for generating only one of the stub 707 and the skeleton 708. Further, when the stub 707 and the skeleton 708 are generated, the computer 1 continuously compiles COBOL and outputs the stub 707 and the skeleton 708 as an executable program. The IDL compiler 700 selects these modes according to parameters of a command that instructs IDL compilation.
[0048]
The stub 707 is activated by a CALL statement that calls a server program in the client program. The activated stub 707 calls the ORB function with the designation of the method name and argument information by the CALL statement. In response to this, the ORB performs processing for specifying the corresponding server program and the computer on which the skeleton 708 is arranged, and calls the skeleton 708 of the arrangement destination computer with designation of method name and argument information. . The skeleton 708 activated in this way calls the server program with an argument specified. Thereby, the server program is executed. The execution result is transferred through the reverse route and passed to the client program.
[0049]
As described above, according to the IDL compiler 700 of the present embodiment, the stub 707 and the skeleton 708 of the COBOL language program including the specification of the data type not supported by IDL is changed from the IDL described by the new description rule. Can be generated.
[0050]
FIG. 6 shows a functional configuration of the IDL generation system of this embodiment.
[0051]
The illustrated IDL generation system 800 includes a syntax analysis unit 802, an interface information extraction unit 804, a conversion table 806, and a code generation unit 807. Each unit 802, 804, 806, and 807 is a function realized by executing a program in the storage area of the disk devices 8 and 9 of the computer.
[0052]
The IDL generation system 800 receives the source file 801 and outputs an IDL source 809. In the course of this process, analysis information 803, intermediate language 805, and code generation information 823 are generated.
[0053]
Here, the source file 801 is composed of a server program described in the COBOL language. The source file 801, analysis information 803, intermediate language 805, code generation information 823, and IDL source 809 are stored as files on the disk device of the computer 1. The source file 801 is transferred via the network 16 from another computer that has been developed, for example.
[0054]
The IDL generation system 800 includes a COBOL type TYPEDEF generation unit 811 incorporated in the TYPEDEF generation unit 808 in the code generation unit 807 and a special table 821 incorporated in the type conversion table 806 as functions for dealing with the new description rule. Have.
[0055]
As shown in FIG. 7, in the special table 821 of the type conversion table 806, COBOL type information and TYPEDEF information are registered in advance in association with each other. Here, the TYPEDEF information is a type definition name (605) described by the new description rule. On the other hand, in the standard table 820 of the type conversion table 806, COBOL type information and IDL type information are registered in advance in association with each other. As a result, all type information in the COBOL language is registered in the type conversion table 806.
[0056]
Note that the type conversion table 806 is placed in the IDL generation system 800 program in order to speed up access. Of course, it may be stored as a file in the disk device of the computer 1.
[0057]
Next, processing of the IDL generation system 800 will be described with reference to FIG.
[0058]
When a message instructing generation of an IDL source is input to the computer, first, the syntax analysis unit 802 performs syntax analysis of the source program 801 and generates analysis information 803.
[0059]
From this analysis information 803, the interface information extraction unit 804 extracts interface information and generates an intermediate language 805. Here, the intermediate language 805 includes the program name of each program constituting the source file 801 and argument information (argument name and type information).
[0060]
Subsequently, the code generation unit 807 reads the intermediate language 805 and performs processing for converting the type information in the argument information into IDL type information or TYPEDEF information, thereby generating an IDL source 809.
[0061]
At this time, the code generation unit 807 first searches the standard table 820 of the type conversion table 806 for the COBOL language type information included in the intermediate language 805. If the type information is registered in the standard table 820 (for example, “PIC S9 (9)”), the code generation unit 807 extracts the corresponding IDL type information (“long”) and generates the code. Register as information 823. This is done for all programs and argument information.
[0062]
The COBOL type TYPEDEF generation unit 811 generates TYPEDEF syntax for COBOL language type information not registered in the standard table 820. First, the TYPEDEF generation unit 811 reads a program name from the intermediate language 805 (S201), and reads argument information that is not registered in the standard table 820 (S202). Then, the type information in the read argument information is searched in the special table 821 of the type conversion table 806 (S203, S205). If the target type information is not registered, type conversion error processing is performed and an error message is displayed (S206).
[0063]
If the target type information is registered, the TYPEDEF information associated with the type information is acquired (S207). Then, the code generation information 823 is searched for whether or not the type definition name that matches the acquired TYPEDEF information is in the TYPEDEF chain (TYPEDEF information group) that has already been output (S208, S210). NO) generates a TYPEDEF syntax using the TYPEDEF information, and additionally outputs it to the TYPEDEF chain in the code generation information 823 (S211). This additional output adds TYPEDEF syntax character data in the form of FIG.
[0064]
As shown in FIG. 3A, in the generation of the TYPEDEF syntax, first, the character data of “typedef long” 600 is set in the syntax, and then the parameter is set in the TYPEDEF information, and the type definition name (605) is set. Generate and set the character data of the type definition name in the syntax. Then, the type definition name (605) and the argument name 606 are set in the next line of the syntax.
[0065]
On the other hand, when a type definition name that matches the acquired TYPEDEF information already exists in the TYPEDEF chain (YES in S209), the type definition name and argument information are added to the location of the matching type definition name in the TYPEDEF chain ( S212). For example, if the type definition name 605 in FIG. 3A exists in the TYPEDEF chain and the type definition name for the other argument name “ARG2” matches that in FIG. 3A, it is already set. "CBL_PACK_9_4V9_3 ARG2" is added to the next row of the type definition name 605 and the argument name 606. Thereby, since it is not necessary to repeatedly set the same information 600 and 605, the information amount of the TYPEDEF syntax can be kept small.
[0066]
Subsequently, the TYPEDEF generation unit 808 repeats the above processing for other argument information of the same program (S213), and further repeats the above processing for other programs (S214).
[0067]
The code generation information 823 created as described above is passed to the code output unit 810. The code output unit 810 sets IDL variable / numerical definition statements using IDL type information in the code generation information 823 for the IDL source 809, and further sets each piece of information in the TYPEDEF chain to the IDL source 809. TYPEDEF syntax.
[0068]
As described above, according to the IDL generation system 800 of the present embodiment, the IDL source 809 described by the new description rule is generated from the COBOL language program including the specification of the data type not supported by IDL. Can do. The developer can obtain the stub 707 and the skeleton 708 by compiling the IDL source 809 with the IDL compiler 700 described above.
[0069]
In other words, by using the IDL compiler 700 and the IDL generation system 800, the developer does not have to modify the interface specification even when diverting an existing client program or server program. The stub 707 and the skeleton 708 can be easily acquired. In addition, a client program and a server program can be created by freely using the COBOL language data type.
[0070]
By the way, although the example which defines the data type which IDL does not support using the TYPEDEF syntax was explained above, this definition is also the IDL variable / constant that the developer can freely describe in IDL. You may make it carry out using a name and the comment sentence of IDL.
[0071]
When the names of variables and constants are used, as shown in FIG. 3B, in the IDL data type definition statement, a partition symbol “_” is inserted in front of the variable or constant name 606 to be defined. The above type definition name 605 is added. In this case, the IDL compiler extracts the name 606 to which “CBL_” is added from the data type definition statement, and performs the same processing as in FIG. The IDL generation system also describes the argument information of the source file in the format of FIG. 3B, and performs the same processing as that of FIG.
[0072]
When using a comment, as shown in FIG. 3C, in the IDL data type definition statement, the comment symbol “//” is inserted after the name 606 of the variable or constant to be defined and the above type definition is inserted. A name 605 is added. Also in this case, the IDL compiler and the IDL generation system perform the same processing as that in FIG. 4 and FIG.
[0073]
Further, the case where development of a program created in the COBOL language is supported has been described above, but the present invention can be easily applied to development using other program languages (for example, C language, C ++ language, Java language, etc.). Can be applied. In this case, in the IDL language processing system, instead of the COBOL dependency information analysis unit 751 and the COBOL type information conversion unit 752, a dependency information analysis unit and a type conversion unit of the target program language are provided, respectively. Further, the IDL generation system is provided with a TYPEDEF generation unit of the target program language instead of the COBOL type TYPEDEF generation unit 811. In the type conversion tables 709 and 806, the data type of the target programming language is registered. Furthermore, the new description rule shall describe the type definition name so that the data type of the target programming language can be uniquely identified.
[0074]
【The invention's effect】
As described above, according to the present invention, it is possible to generate a subprogram that realizes the interface function of the program without restriction on the data type used in the program described in the target programming language. Program development support tools can be provided.
[0075]
Further, according to the present invention, it is possible to provide a program development support tool capable of generating IDL source information that can be processed by the program development support tool for an arbitrary program described in a target program language it can.
[Brief description of the drawings]
FIG. 1 is a block diagram showing a configuration example of a computer on which a program development support tool of the present invention is mounted.
FIG. 2 is a diagram illustrating an example of a type declaration in a COBOL program.
FIG. 3 is a diagram showing a description example of IDL to which the new description rule of the present invention is applied.
FIG. 4 is a diagram illustrating a functional configuration of an IDL language processing system corresponding to COBOL.
FIG. 5 is a diagram illustrating functions of a dependency information analysis unit and a type information conversion unit.
FIG. 6 is a diagram illustrating a functional configuration of an IDL generation system corresponding to COBOL.
FIG. 7 is a diagram illustrating functions of a TYPEDEF generation unit.
FIG. 8 is a diagram showing a functional configuration of a conventional IDL language processing system.
FIG. 9 is a diagram illustrating a functional configuration of a conventional IDL generation system.
[Explanation of symbols]
501 COBOL type declaration statement
600-606 Type declaration using TYPEDEF syntax
605 Type definition name
700 IDL language processing system
701 IDL source
702 Parser of IDL language processor
751 COBOL dependency information analysis section in the syntax analysis section
703 Analysis information obtained by syntax analysis of IDL language processor
704 Code generation unit of IDL language processing system
705 Interface information analysis unit of IDL language processing system
706 Program code generator of IDL language processing system
707 Stub obtained by the code generator
708 Skeleton obtained by the code generator
709 Type conversion table of IDL language processor
Standard table in 710 type conversion table
Special table in 711 type conversion table
712 Code generation information
752 COBOL type information converter
800 IDL generator
801 Primitive program file
802 Syntax analysis part of IDL generator
803 Analysis information of IDL generation system
804 IDL generation interface information extraction unit
805 Intermediate language information of IDL generator
806 IDL generation type conversion table
807 IDL generation code generator
808 TYPEDEF generator in the code generator
810 IDL output part of IDL generation system
811 TYPEDEF generation unit in TYPEDEF generation unit
809 IDL source
Standard table in 820 type conversion table
Special table in type 821 conversion table
823 Code generation information

Claims (6)

Program development for generating a subprogram that realizes the interface function of the program based on IDL (interface definition language) source information that describes the calling rules between a plurality of programs stored in advance in the disk device In the support device,
A special table in which a data type used in the COBOL language, which is a programming language describing the program, and a type definition name in which the data type is described according to a predetermined rule are registered in association with each other , an IDL A storage unit storing a type conversion table having a standard table in which type information and COBOL language type information are registered in advance in association with each other ;
From the source information of the IDL stored in the disk device, the extracted type definitions name that is described according to a predetermined rule, the type definition name and the extracted, using special table of the type conversion table Converting to the COBOL language data type, registering the data type as code generation information in the disk device, and using the registered code generation information to generate the subprogram,
A program development support apparatus characterized by comprising: The program development support apparatus according to claim 1,
The type development name described according to the predetermined rule is extracted from a type definition declaration sentence in the IDL source information. The program development support apparatus according to claim 1,
The program definition support apparatus, wherein the type definition name described according to the predetermined rule includes information indicating a display type, a length, and a use of data. In a program development support device for generating IDL (interface definition language) source information, which describes the calling rules of the program, based on the source code of the program described in the COBOL language stored in advance in the disk device ,
A special table in which a data type used in the COBOL language, which is a programming language describing the program, and a type definition name in which the data type is described according to a predetermined rule are registered in association with each other , an IDL A storage unit storing a type conversion table having a standard table in which type information and COBOL language type information are registered in advance in association with each other ;
Of the data types delivered by the program, the data type registered in the special table is converted into a type definition name using the special table, and the type definition name is converted into code generation information to the disk device. An IDL source generator for registering and generating the IDL source information from the registered code generation information;
A program development support apparatus characterized by comprising: In the IDL program development support device according to claim 4,
The converted type definition name is set in a type definition declaration statement in the IDL source information. The program development support device according to claim 4,
The program definition support apparatus, wherein the type definition name described according to the predetermined rule includes information indicating a display type, a length, and a use of data.

Images