JPH0322141A - Call intermediation system between different languages - Google Patents

Abstract

PURPOSE:To promote the efficiency of software development by dividing an intermediation program into a fixing part and a varying part, and generating the varying part of the intermediation program by preparing a macro. CONSTITUTION:The intermediation program varying part 5 and the intermediation program fixing part 2 are provided, and in response to the call of the name of some program of the language of a calling origin, the corresponding program of the language of a called destination is called by the intermediation program varying part 5 and the intermediation program fixing part 2, and processing is requested. Besides, as for the intermediation program varying part 5, correspondence between the name of the program of the calling origin and the name of the program of the called destination is described by using the macro defined beforehand, and the intermediation program varying part 5 consisting of individual processing is generated automatically by assembling the correspondence, and is linked. Thus, at the time of the software development, various kinds of the programs developed before can be handled as parts, and the efficiency of the software development can be promoted.

Description

[Detailed Description of the Invention] [Summary] Regarding an intermediary method for calling programs between different languages, the intermediary program is divided into a fixed part and a variable part, and macros are prepared to allow the variable part of the intermediary program to be created in NF4. At the same time, the purpose is to reduce the size by consolidating fixed parts in one place, and when a program name in the calling language is called, an entry address is generated to call the program name in the corresponding calling language. , is equipped with an intermediary program variable section consisting of individual processing, and an intermediary program fixed section consisting of a common process that calls a program in the called language based on the entry address notified from this intermediary program variable section, and In response to the call of a program name in a certain language, the variable intermediary program section and the fixed intermediary program section call the corresponding program of the called language and request processing. In addition, for the above-mentioned intermediary program variable part, use a predefined macro to describe the correspondence between the calling program name and the called program name, assemble this, automatically generate the intermediary program variable part, and link it. Configure it to do so.

(Industrial Application Field) The present invention relates to a call mediation method for calling programs between different languages.

[Prior art and problems to be solved by the invention] Generally, when developing software, a description language is selected depending on its intended function. Furthermore, even within a single piece of software, each module may be written in a different language and these may be combined.

At this time, due to the difference in linkage between different languages, it may not be possible to call even if you connect directly.
An intervening program is required to intervene between the two. For example, C in large computers (such as the M series)
The linkage of the OBOL program follows the standard linkage conventions of OSrV. On the other hand, for the linkage of C programs, there is an extended linkage specific to C in addition to the standard linkage convention. For this reason, from a COBOL program
When calling a program, an intermediary program is required to absorb this extension. This mediation program needs to perform the following processing (1+, (2)) as shown in FIG.

(1) Acquire and release the standby area used by the C program.

f2) When the COBOL program attempts to call the C program, it mediates and notifies the C program of the address of the stall area and calls it.

For this reason, each time the number and names of C programs to be called differ, it is necessary to dedicate an intermediary program each time, and there is a problem in that a lot of time and effort is required to create the intermediary program. .

Incidentally, the operation of the third figure structure will be briefly explained. Here, 21
represents a COBOL program, 22 represents an intermediary program, 23 represents a C program, and 24 represents a stack area. In FIG. 3, ■:21 calls the initialization process of 22. 22 dynamically acquires 24 and stores its start address inside 22. ■=22 returns to 21.

■: 2l requests 22 to call SUB 1. ■: 22 calls 23 without notifying 24 of its address. At this time, funcl corresponding to SUB 1 is selected.

■: 23 processes f unc 1 and returns to 22.

■: 22 returns to 21.

■ to [phase] are carried out in the same way as the processes of ■ to ■.

■=21 calls the termination process of 22. 22 is 24
release.

@:22 returns to 2l.

The present invention divides the intermediary program into a fixed part and a variable part,
The purpose is to prepare macros to easily create the variable parts of the intermediary program, and to reduce the size of the fixed parts by consolidating them into one meter.

[Means to solve problems]

The means to solve the problem will be explained with reference to Figure 1. In FIG. 1, the intermediary program variable unit 5 has an entry address for calling a program name (for example, func 1) in the corresponding language of the call destination when a certain program name (for example, SUB 1) in the language of the call source is called. It consists of individual processing to generate . The fixed intermediary program section 2 consists of a common process of calling a program in the called language based on the entry address notified from the variable intermediary program section 5. [Operation] As shown in FIG. 1, the present invention has a method for calling a program name (for example, func 1) in the corresponding language of the calling destination when a certain program name (for example, 5118 1) in the calling language is called. A fixed intermediary program consisting of a common process that calls a program in the called language based on the entry address notified from the intermediary program variable section 5, which generates the entry address of the intermediary program variable section 5. A section 2 is provided, and in response to the call of a certain program name in the calling source language, the intermediate program variable section 5 and the intermediate program fixed section 2 call the corresponding program in the called destination language and request processing. For the intermediary program variable section 5, a predefined macro is used to describe the association between the calling program name and the called program name, and this is assembled to create the intermediary program variable section 5 consisting of individual processing. It is automatically generated and linked. Therefore, by dividing the intermediary program into a fixed part and a variable part, and preparing macros, it is possible to easily create the intermediary program variable part 5, and it is also possible to reduce the size by consolidating the intermediary program fixed parts 2 into l locations. becomes. [Embodiment] Next, the configuration and operation of an embodiment of the present invention will be explained in detail using FIGS. 1 and 2.

In FIG. F, COBOL program 1 is a program that calls a program written in C program 3 and requests processing.

The intermediary program is composed of an intermediary program fixed section 2 and an intermediary program variable section 5, and is a program that performs intermediation by calling a program written in the C program 3 in response to a call from the coBOL program 1. Here, common processing is written in the intermediary program fixed part 2, and individual processes are written in the intermediary program variable part 5, so that they are separated. This large intermediary program variable part 5 depends on the number and names of C programs to be called.
All you need to do is discipline yourself (see Figure 2).

Next, the operation of the configuration shown in FIG. 1 will be explained in detail. Hereinafter, 1 represents the COBOL program, 2 represents the fixed part of the intermediary program, 3 represents the C program, 4 represents the standby area, and 5 represents the variable part of the intermediary program. ■:l calls the initial processing of 2. 2 dynamically acquires 4 and stores its start address inside 2.

■: 2 returns to l.

■:l requests 5 to call SUBI. ■: 5 calls the common process of 2 without notifying the entry address of funcl. ■=2 calls f unc 1.

■: Return to 2 from funcl.

■: 2 returns to 5.

■: 5 returns to 1.

■ to [phase]: These are the same as the processes for ■ to ■, except that the entry location for 5 is SUB2. ■: 1 calls the termination process of 2. 2 releases 4.

@l returns to 1.

Through the above processing, the COBOL program 1 can call the corresponding program of the C program 3 via the intermediary program variable section 5 and the intermediary program fixed section 2 and request processing.

At this time, it is only necessary to dedicate only the intermediate program variable section 5 depending on the number and names of C programs to be called. The intermediary program fixed part 2 can be used in common.

Next, the operation of the intermediary program variable section 5 will be explained in detail using FIG.

In FIG. 2, numeral 11 indicates an assembler source for the variable section. For example, ■Pa, predefined macro 1\BR t
The calling COBOL program using "DGE"
Describe the correspondence between the program name "SUBI" and the program name "FtJNc1" of the called C program 3. 12 assembles the assembler source of the variable part 1l with reference to the macro definition body 13 to generate an object (object of the intermediary program variable part 5).

15 is a linkage editor that creates 14 objects (intermediary program variable section 5), an intermediary program fixed section 2 prepared in advance, and a COBOL program l1.
and C program 3. As a result, an executable module with the structure shown in Figure 1 will be created. [Effects of the Invention] As explained above, according to the present invention, an intermediary program is divided into a fixed part and a variable part, and a macro is prepared to control the variable part of the intermediary program. In addition, the variable intermediary program section 5 can be easily created, and the fixed intermediary program section 2 can be consolidated into one location to reduce its size. This allows COBOL
When developing software using a language such as the C language, various programs that have already been developed can be handled as components, making it possible to improve the efficiency of software development and flexibly design the program structure.

[Brief explanation of drawings]

FIG. 1 shows the structure of one embodiment of the present invention, FIG. 2 shows an explanatory diagram of the discipline of the variable part of the intermediary program according to the present invention, and FIG. 3 shows an explanatory diagram of the prior art. In the figure, 1 is a COBOL program, 2 is a fixed part of the intermediate program, 3 is a C program, 4 is a pass tank area, 5 is a variable part of the intermediate program, 11 is the assembler source of the variable part, and 13 is a macro definition body.

Claims (2)

[Claims] (1) In an intermediary method for calling programs between different languages, it consists of individual processing that generates an entry address to call the program name of the corresponding destination language when a certain program name of the calling source language is called. It is equipped with an intermediary program variable section (5) and an intermediary program fixed section (2) consisting of a common process that calls a program in the called language based on the entry address notified from the intermediary program variable section (5). , The system is configured such that, in response to a call of a certain program name in the caller's language, the intermediary program variable section (5) and the intermediary program fixed section (2) call the corresponding program in the callee's language and request processing. A method for mediating calls between different languages. (2) For the above-mentioned intermediary program variable section (5), use a predefined macro to describe the correspondence between the calling program name and the called program name, and assemble this to assemble the corresponding intermediary program variable section (5). ) is configured to automatically generate and link the call mediating system between different languages according to claim (1).