JPH01161567A - Program developing system of decentralized processing system - Google Patents

Abstract

PURPOSE:To improve the program developability of a decentralized processing system by separating the attribute information related to an input-output message defined on a program when source programs are compiled and making the attribute information to correspond to the load module of a compiled result. CONSTITUTION:Programs 15001, 15002, and 15003 are assembled in the processor 15 of a developing system and each of the programs is actuated in accordance with an input from a CRT terminal 1501. The program 15001 generates load module files 3501-350n and an attribute file 3500 against a designated file of source program files. The program 15002 generates a loading message in accordance with the contents of the files 3501-350n and file 3500 and the program 15003 correlates the programs in accordance with the contents of the file 3500. Therefore, information necessary for loading the programs can be automatically generated and the relations among the programs can be recognized by only defining the information related to the input-output on a source program. Thus the soft developability of this system is improved.

Description

[Detailed Description of the Invention] C Industrial Field of Application] The present invention is a distributed processing system in which a series of processes are executed by a plurality of processors. This article relates to a program development method for loading onto each processor.

[Conventional technology]

In a distributed processing method in which a series of 12 tasks is distributed and processed by processors connected to a common transmission path,
Programs for executing each of the series of processes are distributed and stored in each processor, and each processor's program is activated by importing the data necessary to execute this program from the transmission path into the self-device, and when all the data is available. For example, Japanese Patent Laid-Open No. 57-146361 discloses a method for this purpose. This method does not require a management processor to manage the entire system.
This allows each processor to perform a series of processes in a distributed manner.

In addition, for the above distributed processing system, the program itself that executes processing within each process is also considered a message.
For example, there is a method in which each processor takes in the programs it needs from among the programs flowing on the transmission path and stores them in 0.
This is shown in Publication No. 9.

[Problems to be solved by the invention] □ In the distributed processing system shown in the above-mentioned prior art, the interface between each program is defined only by the input/output data of each program, so each program can be developed individually. It is. However, in the above-mentioned conventional technology, there is no method for checking whether or not the relationships between individually developed programs are consistent, which poses a problem in program development.

Furthermore, in the above conventional technology, when loading the developed program into each processor, it is necessary to define the program's input/output messages, but if incorrect information is defined at this time, the program will not receive the intended message. The problem is that the process is executed using a completely different message.

An object of the present invention is to enable the above-mentioned distributed processing system to check the consistency of relationships between programs under development, and to automatically generate information necessary for loading from program attribute information in a loading processor example. The object of the present invention is to provide a program development method that improves developability.

[Means for solving problems]

The above purpose is to separate the attribute information regarding input/output messages defined on the source program when compiling the source program, store it in association with the load module of the compilation result, and to associate programs between programs based on the attribute information. This is achieved by creating a table showing the

[Effect]

By using the above means, input/output information can be obtained for each program under development, and by relating the input/output information for each program, the relationship between the programs under development can be grasped and their consistency You can check the gender. Furthermore, when loading a program, it is possible to automatically generate a loading message consisting of the program's load module and its input/output information.

〔Example〕

Hereinafter, the present invention will be explained in detail with reference to Examples.

2m is a diagram for explaining a system to which the present invention is applied. FIG. 2(a) is a diagram showing an example of the overall system configuration. In this figure, 11 to 14 are processors that store application programs therein and execute them.

Further, 15 is a processor for developing programs to be executed within the processors 11 to 14, and a disk 150
2. A CRT terminal 1501 is connected. Processors 11 to 15 are connected to the network 1, which will later be connected to the development system. Here, the network 1 may be any type of network, and the processing results (data) of the processors 11 to 14 are sent out onto the network. In addition, each processor takes in the messages necessary for executing the confession program from among the messages flowing on the network,
Start the program when you have all the messages necessary for execution. The activated program executes its own processing and outputs the results.

FIG. 2(b) is a diagram showing the format of messages flowing on the network 1. CC202 is a content code, which is a code corresponding to the content of data.Each processor is based on this content code.

Determine whether the message received from the network is necessary for the confession program.

5A203 is the address of the processor that generated the message, and C2O4 is the serial number necessary for transmission. D
ata205 indicates the contents of the results processed by each program, FC8206 indicates error detection data, F2
01 and 207 are flags indicating the beginning and end of the message, respectively.

FIG. 2(Q) shows an example of a table that each processor has for determining whether to start a confession program. Figure 2 (
Each row 1051 of the table shown in c).

1052, . . . are lines corresponding to each program.

Prog10512 on the first line is an area that stores information about the program to be started, and IData105
11 is Prog 10512 received from the network
This area stores messages necessary for program execution.

The second and subsequent lines have a similar configuration. Here, the IData 10511 section of this table stores in advance the message content code necessary for the execution of each program, and each processor sets it in the 00 section 202 of the message received from the network and the internal table of its own processor. Compare the content code with the matching °ID
Store the message in ata area 10511 m I
When all necessary messages are stored in the Data area 10511, the processor executes the program in the Plog area 10512.

Hereinafter, a program development method, which is one aspect of the present invention, which is intended for programs running on the above system, will be explained in detail using FIG. 1 and FIGS. 3 to 7.

FIG. 1 is a diagram showing a program installed in the development system processor 15 to realize the 1-hydro type.

Programs 15001 and 15002 are in the processor 15.
, 15003 are incorporated, and each of these programs is activated in response to input from a display (CRT) terminal 1501. The program 15001 is a program that generates load module files 3501 to 350n and an attribute file 3500 for a file specified from among the source program files (3011, 3012, . . . ). Bu. Program 5A15002 is a program that creates a loading message based on the contents of the load module file and attribute file and outputs it to network 1, and program 15003 is the attribute file 3.
There is a programmer that associates programs based on the contents of 500. The processing contents of each of these programs will be explained below. First, the processing of the program 15001 will be explained with reference to FIGS. 3 and 4. Figure 3 is the first
The zero source program files that indicate the contents of the source programs 3011 to 301n in the figure are written in advance.
For example, it is assumed that the information is input by a program developer using the CRT terminal 1501. The source program targeted by this method is composed of an attribute section 401 and a program section 402. The attribute section 401 includes a program name definition section 4011, an input message content code definition section 4012,
It consists of an output message content code definition section 4013 and information for testing this program (for example, data indicating test inputs and their results) 4014. Further, the program section 402 shows the coded program contents.

FIG. 4(a) shows the processing flow of the program 15001. The program 15001 starts processing by specifying, from the terminal 1501, a source program file to be converted into a load module. The program 15001 first separates the specified source program into an attribute section and a program section (processing 551), and then performs a format check on the separated attribute section (processing 552). Check whether the contents are as shown in FIG. 3 401. If the result of this format check is OK, the process advances to step 554; if not, an error message is output (step 557) L, and the process ends. In process 554, a load module file is generated by compiling the program portion separated in process 551. If the compilation ends normally, process 556
If the process ends abnormally, an error message is output (step 557), and all processes are terminated. In process 556, an attribute table is created based on the attribute part contents whose format check is OK, and an attribute file (350 in FIG. 1) is created.
The structure of the attribute file and load module file created by the above process is shown in FIG. 4(b).The attribute file 3500 is stored in process 556) in FIG. Each created load module file 3501.3502. . . , attribute tables 35001.35002. ... is stored. The table 35001 includes an area P N350011. which stores the program name 4011 defined in the source program attribute section 401 of FIG. Area I CC350012 that stores the input message content code 4012, which is also defined in the attribute section 401.
, the area OCC350013 for storing the output message content code 4013, and the areas PN, IOC, O
File pointer indicating a load module file created from a source program with CC attribute F P 3
Consists of 50014. Table 35002.35
003. ... has the same configuration. Note that the load module files 3501, 3502, . . . are always accessed via the attribute tables 35001, 35002, . That is, the load module file is accessed by program name. Therefore, when deleting a load module file, the corresponding attribute table should also be deleted at the same time. In addition, Fig. 4 (a
), if an attribute table with the same program name PN exists in the structure, the attribute table is created after deleting the already existing attribute table and its corresponding load module file.

Next, the program for creating the loading message 15002 in FIG. 1 will be described with reference to FIG. 5. This program executes processing by specifying the program name of the program to be loaded from the CRT terminal (1501 in FIG. 2). First, the attribute table having the PN section (FIG. 4(b)) that matches the specified program name is searched from within the attribute file (process 581), and then,
A loading message is created from the retrieved attribute table and the corresponding load module (processing 58).
2) The contents of the Data section (205 in FIG. 2(b)) of the loading message created in process 582 are shown in FIG. are areas for setting the input content code ICC section and the output content code 1000 copies of the attribute table, respectively.

The contents of the load module file are set in the LM594. Further, a content code corresponding to each program is set in the CC section (202 in FIG. 2(b)) of the loading message. The program 15002 is shown in FIG.
), the message is sent to the network (process 583).The loading message created by the process shown in Figure 5 and sent to the network is received by each processor connected to the network. and C in the loading message.
The C section determines whether the program in the message is necessary for itself, and only if necessary incorporates the received loading message into the confession.The processor that has incorporated the loading message into the confession will The LM contents are stored in the confession memory area, and the currently loaded program is stored in the program registration table shown in FIG. 2(c) based on the PN, IOC, and OCC contents of the message data section. Next, test launch the loaded program using the test information in the attribute information, judge the output, and confirm that the test is OK.
In this case, the program is brought online. Note that in the above processing, it is assumed that each processor has a content code that indicates a program necessary for itself registered in advance.

Next, the processing of the program 15003 (FIG. 1) for associating programs based on the content of attribute files will be explained using FIGS. 6 and 7.

FIG. 6(a) shows an input/output related table created by the program 15003. The personal output related table consists of rows 601, 602, . . . corresponding to each content code. The first line 601 is an area CC6011 that stores content: l-5, an area IPROG 6012 that stores the name of the program that inputs the message with the content code of this area C66011, and an area that outputs the message with the content code of area CC6011. It consists of an area 0PROG 6013 that stores the name of the program. Second
The configuration after the row is the same.

FIG. 6(b) is a diagram showing a processing flow for creating the input/output related table shown in FIG. 6(a). First, a counter variable i is initialized (process 651), and then an input/output related table is set based on the contents of the first attribute table (FIG. 4(b)) (process 652). Specifically, The input/output related table is set according to the float shown in FIG. 6(C). First, search the input/output related table for a row in which a content code that matches the content code set in the ICC part of the attribute table is set in the CC part (
Process 681), if the corresponding line exists, to the IPROG area 6012 of that line.

The contents of the attribute table PN section are set (processing 682).

If the corresponding row does not exist, a new row is added to the input/output related table, and the CC section of that row is added.

Each IPROG section contains an ICC section of an attribute table.

Next, the contents of the PN section are set (process 683).

The input/output related table is searched for a row in which a content code that matches the content code set in the 006th part of the attribute table is set in the CC part (processing 684), and if a corresponding row exists, the line is Set the contents of the attribute table PN part in the 0PROG area (process 685). If the corresponding row does not exist, add a new row to the input/output related table, and set the CC part and 0PROG part of that row, respectively. The contents of the 000 part and the PN part of the attribute table are set (process 686). After the process in FIG. 6(c) is completed, check whether this process has been completed regarding the metal property table in the attribute file (process 653). , if not completed, the counter variable i is incremented by 1 (step 654), and the process returns to step 652.

From the input/output related table created by the above process, for any content code, a program that uses it as input,
Also, it becomes possible to grasp the program to be output. In addition, one table of engineering PROG area or 0PR
By searching for a line in which the OG area is not set, it is possible to detect a program for which there is no program that generates the input message, or a program for which there is no program that takes in the output message. This is an example of abnormality detection in the relationship between programs.

In addition, a series of programs that are activated in response to an arbitrary message can be detected using the personal output related table. Next, the process for this purpose will be explained with reference to FIG.
This process starts by specifying the content code of the message that is the trigger. First, after setting the internal counter Ω to O (process 700), a program that inputs the specified content code is detected from the input/output related table.

This is defined as the a-th level program (process 701).

Next, for each detected a-th level program, a program that uses the output message as an input is searched, and this is set as the (Ω+1)-th level program (processing 702).
This is achieved by detecting the content code of each output message from the attribute table corresponding to each program, and detecting the program whose input is the code of the output message content from the input/output related table. For the (Q+1)th level program detected in process 702, it is checked whether a matching program exists among the programs searched so far (Oth to Qth level programs), and if it exists, the program is (α+1)
Loop check is disabled for the level program (process 703). This is a process for detecting a structure as shown in FIG. 7(b). In FIG. 7(b), 761,
762 indicates a program, 751 indicates a message with content code CC1, and 752 indicates a message with content code CC2. In the 0-line structure, the flow of processing is a loop such that program 761 is started by the output message of program 762. Therefore, the process 703 is also an example of detecting an abnormality in the relationship between programs.Next, the process moves to process 704, and the (fi + 1)th level is detected. Checks whether the program exists, and if it does not exist, ends the process.

If it exists, increase the internal variable Q by 1 and perform process 70.
Return to 2. In addition, in process 704, it is assumed that a (fi+1)th level program does not exist for programs that cannot be loop-checked.

on the source program using the method shown above.

Just define information about input and output messages.

It becomes possible to automatically generate information for loading the program into the execution processor. Furthermore, it becomes possible to understand the relationships between programs and detect abnormalities in those relationships.

In addition, in this embodiment, the attribute table of each program is
It was supposed to be generated together with that load module, but
It is also possible to generate only the attribute table without generating a load module. Furthermore, even if only attribute sections are defined in the source program, this method of checking inter-program relationships is applicable. Furthermore, in this embodiment, the attribute table is stored in a file separate from the load module, but it is also possible to store each load module and its corresponding attribute table in the same file and treat them as one. be.

Also, in one embodiment? Although the target is a system composed of several processors, the 1-hydro formula can be similarly applied to a system composed of a single processor (a system in which the development system and execution system are not separated).

In addition, in this embodiment, the processor that loaded the program tests using the test information in the program attribute information, but in the development system, the program developed based on the program attribute information can also be tested. It is possible to perform tests automatically.

【Effect of the invention〕

As described above, according to the present invention, in a distributed processing system in which a series of processes are executed by a plurality of processors,
When developing a program to be incorporated into each processor, simply by defining input/output information on the source program, the information necessary for loading can be automatically generated. Since it is possible to detect the relationship between In addition, the reliability of the software is improved because it is possible to grasp the relationship between programs and detect abnormalities in the relationship between programs in advance only on the relational system without loading it into each processing device and actually running it.

[Brief explanation of the drawing]

FIG. 1 is a diagram showing an example of a program to be incorporated into a development processor that implements the program development method of the present invention, FIG. 2 is a diagram for explaining a system in which the program developed according to the present invention is incorporated, and FIG. FIGS. 4 to 7 are diagrams illustrating an example of the format of a source program targeted by the program development method of the present invention. FIGS. 1±1 are diagrams for explaining the present invention in detail. CC...content code, Data...data part within the message, PN...program name, CC...input content code, OCG...output content code, FP...
File pointer, LM...load module, IP
ROG...Input Pro■ /a /fO;L 2nd concave (b) (Cnshi〒-°Stomach 1〉 Theory 2 Yobato 31!1 Fig. 4 (α) 52nd (Kun Ll-j Road 7) 'Ale No. 6 Old (α) Fig. 6 (C)

Claims (1)

[Claims] 1. In a distributed processing system in which a series of processing is executed by programs in a plurality of processing devices connected by a transmission medium, the program is executed from each program in at least one processing device. Separate the program part that shows the attribute information regarding the input/output data and the program contents,
A program development system characterized in that a message having the separated attribute information and a program section as paired data is sent to the transmission medium, and the programs are associated based on the content of the attribute information. method. 2. The program development method according to item 1, wherein each processing device loads messages necessary for itself based on attribute information of the message sent to the transmission medium. 3. The program development method according to item 1 or 2, characterized in that a file is created in which the separated attribute information and the program section are paired data. 4. The program development method according to item 1 or 2, characterized in that a table for associating programs is created based on the attribute information. 5. The program development method according to item 1 or 2, wherein the attribute information includes information for testing the program.