JP2009075724A - Management apparatus, management system, management program, and management method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an apparatus, a program, and a method for executing only part of a job in a workflow, in a debugging mode. <P>SOLUTION: A program of a first job in the workflow is started in the debugging mode, and a program of a second job of the workflow is started in a normal mode. Additionally, by allowing a scheduler to rewrite an effective mode in a mode table defining whether to execute each job in the normal mode or the debugging mode, the mode for job execution can be dynamically changed. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a management device, a management system, a management program, and a management method.

  Patent Document 1 discloses a technique for creating a program in a function block format, providing an execution flag for determining whether to execute a function block, and executing only the function block indicating that the execution flag is executed.

  Patent Document 2 discloses a technique for executing a part of a program in a debug mode and the other in a non-debug mode according to the presence / absence of a debug mode display using a mode switching unit inserted in the program.

  Patent Document 3 discloses that a debugger operation can be described and registered in a custom handler in response to an event.

JP 2005-310056 A Japanese Patent Laid-Open No. 11-306042 JP-A-11-110250

  None of the techniques described in the above-mentioned patent documents starts the program of the first job in the workflow in the debug mode and the program of the second job in the normal mode. Therefore, there is a problem that only some jobs in the workflow cannot be executed in the debug mode. The objective of this invention is providing the management apparatus, management system, management program, and management method which solve the said subject.

  The management apparatus according to an embodiment of the present invention activates the program of the first job in the workflow in the debug mode and activates the program of the second job in the workflow in the normal mode.

  A management program according to an embodiment of the present invention causes a computer to execute a process of starting a program of a first job in a workflow in a debug mode and starting a program of a second job in the workflow in a normal mode. .

  In the management method according to an embodiment of the present invention, the computer starts the program of the first job in the workflow in the debug mode, and starts the program of the second job in the workflow in the normal mode.

  The present invention provides a management device, a management system, a management program, and a management method that can execute only a part of jobs in a workflow in a debug mode.

  FIG. 1 shows a configuration of a management system 10 according to the first embodiment of the present invention. The management system 10 includes a management device 20, a resource device 30, and a client terminal 11 connected via a network. There are usually a plurality of resource devices 30, but one resource device 30 may be used.

  The management device 20 includes a scheduler 21, a debug server 22, a command storage unit 40, a workflow 50, and a management program 23. The workflow 50 is stored in a disk device (not shown) of the resource device 30.

    In the present embodiment, the scheduler 21 and the debug server 22 may be realized by hardware, or the processor provided in the management apparatus 20 reads and executes the management program 23 stored in the storage area and is equivalent. It may be implemented to perform a function.

  The resource device 30 includes an agent 33, a debugger 31, and a user process 32.

  In the present embodiment, the agent 33 and the debugger 31 may be realized by hardware, or an equivalent function is obtained when the processor of the resource device 30 reads and executes a program (not shown) stored in the storage area. It may be realized to fulfill

  FIG. 2 shows the workflow 50. The workflow 50 includes a job 51 and a flow description 59. There are usually a plurality of jobs 51, but one job 51 may be used.

  The flow description 59 is a file describing the execution flow of the job 51 belonging to the workflow 50. The flow description 59 corresponds to a description (flow chart) of an execution flow with the job 51 as a step. FIG. 2 illustrates this flowchart. This flow description 59 defines the execution order of jobs 51, selection or branch conditions, repetition conditions, and the like.

  The flow description 59 can also define a variable, and the completion code of the job 51 and the value of the system variable of the management apparatus 20 can be assigned to the defined variable, and can be calculated and compared. The flow description 59 controls the execution of the job 51 based on the result of this calculation or comparison.

  Here, the system variable refers to a storage area for storing a value indicating a system attribute or state managed by the management apparatus 20 so that the software can refer to it. The system variable stores, for example, date / time information, the number of processors, a processor usage rate, a memory usage rate, and software version information.

  The job 51 includes a job ID 52, a program 53, a resource requirement 56, and a mode specification 57. In addition, the job 51 normally includes the input file 54 and the output file 55, but it does not have to be provided.

  The job ID 52 is an identifier unique within the management system 10 of the job 51. The program 53 is executed as the job 51. During execution, the program 53 inputs data from the input file 54 and outputs the data to the output file 55. The input file 54 and the output file 55 may be different files or the same file.

  The job 51 may update a database (not shown) provided in the resource device 30.

  The job 51 is scheduled to be executed by the scheduler 21 as part of the workflow 50. At this time, the scheduler 21 selects one or a plurality of resource devices 30 that execute the program 53 based on the resource requirement 56.

  In the selected resource device 30, the agent 33 activates the program 53 of the job 51. The processor of the resource device 30 executes the activated program 53 as the user process 32. Here, the user process 32 is a unit of execution control in the resource device 30. The user process 32 is sometimes called a task.

  The resource requirement 56 is a file in which information necessary for selecting the resource device 30 described above, such as the required number of processors, the type of an OS (Operating System) such as UNIX (registered trademark), the required memory amount, and the like is described.

  The mode designation 57 is an information file that designates whether the program 53 of the job 51 is executed in the normal mode or the debug mode. If the mode specification 57 is omitted, it may be interpreted that the normal mode is specified.

  Here, executing the program 53 in the debug mode means executing the program 53 with an environment set so that the debug function provided by the debugger 31 can be applied to the program 53. The debug function refers to a function such as interrupting the execution of the program 53 at a breakpoint address designated by the user or acquiring trace information at a checkpoint address designated by the user.

  In the debug mode, part of the instructions of the program 53 may be rewritten and executed so that the debugger 31 can interrupt the execution of the program 53 and intervene. Further, the debugger 31 may execute the program 53 by setting the processor of the resource device 30 to the debug mode. When the processor is set to the debug mode, for example, the processor generates an interrupt for debugging every instruction.

  Various techniques for executing the program 53 in the debug mode are known to those skilled in the art, and any of them may be used in the present invention. Various debugging functions provided by the debugger 31 are known to those skilled in the art, but this embodiment does not depend on a specific debugging function.

  FIG. 3 shows the configuration of the command storage unit 40. The command storage unit 40 includes a job ID 41 and a command character string 42 that exist corresponding to the job 51.

  FIG. 4 is a flowchart of the scheduler 21. When the workflow 21 is input, the scheduler 21 analyzes the flow description 59 and acquires information on the job 51 to be executed (S41).

  If there is a job 51 to be executed (Y in S42), the scheduler 21 selects a resource device 30 that executes the job 51 based on the resource requirement 56 (S43). The selection technique is known to those skilled in the art in fields such as grid computing, and details are omitted. The scheduler 21 transmits the program 53 of the job 51, the input file 54, and the definition information of the job 51 to the selected resource device 30 (S44).

  If the mode designation 57 of the job 51 is the debug mode designation (Y in S45), the scheduler 21 activates the debug server 22 (S46). Thereafter, the scheduler 21 waits for completion of the debug server 22 (S47). Note that the debug server 22 internally starts the program 53 and waits for its completion.

  After the waiting, the scheduler 21 receives the output file 55 of the job 51 from the resource device 30 (S48), and executes the schedule of the next job 51 based on the flow description 59 (S41).

  If the mode designation 57 of the job 51 is not the debug mode designation (N in S45), the scheduler 21 designates the normal mode to the agent 33 of the resource device 30 and transmits an activation request for the program 53 (S49). . Thereafter, the scheduler 21 waits for the completion of the program 53 (S4A).

    After the waiting, the scheduler 21 receives the output file 55 of the job 51 from the resource device 30 (S48), and executes the schedule of the next job 51 based on the flow description 59 (S41).

  If there is no job 51 to be executed (N in S42), the scheduler 21 terminates the processing of the workflow 50 and waits for the input of the next workflow 50.

  5 and 6 are flowcharts of the debug server 22. FIG. 5 shows the overall flow of the debug server 22.

  When the debug server 22 is activated, it connects to the client terminal 11 (S51). This is because the debug server 22 inputs a debug command from the client terminal 11 and outputs a debug command execution result to the terminal.

  The debug server 22 designates the debug mode and transmits a request to start the program 53 to the agent 33 of the resource device 30 (S52). Thereafter, the debug server 22 transmits the debugger 31 to the agent 33 (S53). If the debugger 31 is resident in the resource device 30, this transmission is not necessary.

  The debug server 22 checks whether the command character string 42 corresponding to the job 51 being processed is registered in the command storage unit 40 (S54). That is, the debug server 22 scans the command storage unit 40 to find a job ID 41 that matches the job ID 52 of the job 51 being processed, and determines whether the corresponding command character string 42 is a null value (for example, all blanks). To check.

  If the command character string 42 corresponding to the job 51 being processed is not registered in the command storage unit 40 (N in S54), the debug server 22 inputs a debug command and transmits it to the debugger 31 (S55). FIG. 6 shows this detail.

  If the command character string 42 corresponding to the job 51 being processed is registered in the command storage unit 40 (Y in S54), the debug server 22 receives the command character string 42 corresponding to the job 51 being processed from the command storage unit 40. Is acquired (S5B) and transmitted to the debugger 31 (S5C).

  The debug server 22 waits for a response from the debugger 31 (S56). If the response is not an end report (N in S57), the debug server 22 reports the interruption due to the breakpoint of the program 53 to the client terminal 11 (S58). Thereafter, the debug server 22 inputs a debug command and transmits it to the debugger 31 (S59), and waits for a response (S56).

  If the response from the debugger 31 is an end report (Y in S57), the debug server 22 reports the end of the program 53 to the client terminal 11 and the scheduler 21 (S5A) and ends.

  FIG. 6 is a flowchart of debug command input and the like of the debug server 22.

  The debug server 22 inputs a debug command from the client terminal 11 (S61). If an explicit job ID 52 is not specified in the input debug command (N in S62), it is checked whether the input debug command is an object to be repeatedly executed (S63). The debug server 22 may determine whether or not the input debug command is an object to be repeatedly executed using the instruction part of the debug command. The debug server 22 may determine this with the parameters of the debug command.

  If the input debug command is to be repeatedly executed (Y in S63), the debug server 22 registers the debug command in the command storage unit 40 in association with the job 51 being processed (S64). That is, the debug server 22 scans the command storage unit 40, finds the job ID 41 that matches the job ID 52 of the job 51 being processed, and stores the debug command input in the corresponding command character string 42.

  Thereafter, the debug server 22 transmits the input debug command to the debugger 31 of the resource device 30 (S66).

  If the input debug command is not the object to be repeatedly executed (N in S63), the debug server 22 deletes the command registration corresponding to the job 51 being processed (S65). That is, the debug server 22 scans the command storage unit 40, finds the job ID 41 that matches the job ID 52 of the job 51 being processed, and sets the corresponding command character string 42 to the Null value.

  Thereafter, the debug server 22 transmits the input debug command to the debugger 31 of the resource device 30 (S66).

  If an explicit job ID 52 is specified in the input debug command (Y in S62), the debug server 22 checks whether the input debug command is an object to be repeatedly executed (S67).

  If the input debug command is to be repeatedly executed (Y in S67), the debug server 22 registers the debug command in the command storage unit 40 in association with the designated job ID 41 (S68). That is, the debug server 22 scans the command storage unit 40, finds the designated job ID 41, and stores the input debug command in the corresponding command character string 42.

  Thereafter, the debug server 22 inputs a new debug command from the client terminal 11 (S61).

  If the input debug command is not the object to be repeatedly executed (N in S67), the debug server 22 deletes the command registration corresponding to the designated job ID 41 (S69).

  Thereafter, the debug server 22 inputs a new debug command from the client terminal 11 (S61).

  FIG. 7 is a flowchart of the agent 33 of the resource device 30. The agent 33 is resident and operating in the resource device 30.

  The agent 33 receives the program 53 of the job 51, the input file 54, and the definition information of the job 51 from the scheduler 21 (S71). The agent 33 checks whether or not the debug mode is designated by the start request of the program 53 received from the scheduler 21 or the debug server 22 (S72).

  If the debug mode is designated (Y in S72), the agent 33 receives the debugger 31 (S73). If the debugger 31 is resident in the resource device 30, this reception is not necessary. The agent 33 activates the debugger 31 and waits for its end (S74). After the end of the debugger 31, the agent 33 transmits the output file 55 of the job 51 to the scheduler 21 (S75), and the process ends.

  If the debug mode is not designated (N in S72), the agent 33 activates the user process 32 for executing the program 53 in the normal mode and waits for the end (S76). After the end of the program 53, the agent 33 transmits an end report to the scheduler 21 (S77), transmits the output file 55 of the job 51 to the scheduler 21 (S75), and ends the processing.

  FIG. 8 is a flowchart of the debugger 31.

  The debugger 31 inputs a debug command from the debug server 22 (S81). When the input debug command instructs to start the program 53 (Y in S82), the debugger 31 starts the user process 32 for executing the program 53 in the debug mode, and waits for its termination or interruption (S84). As described above, various techniques for executing the program 53 in the debug mode are known to those skilled in the art, and details thereof are omitted here.

  When the program 53 is terminated (Y in S85), the debugger 31 sends a termination notification of the program 53 to the debug server 22 and the agent 33 (S89).

  When the program 53 reaches an interruption point (break point) (N in S85 and Y in S86), the debugger 31 transmits an interruption point report to the debug server 22 (S87), and a new one is received from the debug server 22. A debug command is input (S81).

  If the processing of the program 53 is interrupted for other reasons (N in S86), processing corresponding to that is performed. As this process, for example, there is trace information acquisition (S8A) when a checkpoint is reached.

  When the input debug command instructs the end of the program 53 (N in S82 and Y in S83), the debugger 31 sends an end notification of the program 53 to the debug server 22 and the agent 33 (S89).

  If the input debug command is other (N in S83), the debug command is processed and the result is transmitted to the debug server 22 (S88). This processing includes, for example, display and update of a specific memory.

  FIG. 9 shows characteristic components of this embodiment. The management apparatus 20 starts the program 53 of the first job 51 in the workflow 50 in the debug mode, and starts the program 53 of the second job 51 in the same workflow 50 in the normal mode.

  The first effect of the present embodiment is that only a part of jobs 51 in the workflow 50 can be easily debugged regardless of the scale and complexity of the workflow 50.

  This is because the scheduler 21 selects normal mode execution or debug mode execution of the program 53 in accordance with the mode designation 57. Accordingly, it is not necessary for the creator of the workflow 50 to divide the workflow 50 into individual jobs 51 and repeat the normal mode execution or the debug mode execution for each.

  The second effect is that the workflow 50 involving a large amount of input / output can be easily debugged.

  This is because the user can debug the specific job 51 while the scheduler 21 executes the entire workflow 50. Therefore, the user does not need to prepare in advance the input file 54 (the output file 55 of the job 51 executed before the target job 51), which is the premise of the program 53 to be debugged.

  A third effect is that debugging of the workflow 50 including repetition of job 51 execution with a large number of repetitions can be easily performed.

  The reason is that the scheduler 21 activates the debugger 31 every time the job 51 is repeatedly executed, and the debug server 22 repeatedly inputs the debug command registered in the command storage unit 40.

  The fourth effect is that debugging can be performed without changing the execution scale of the job 51 input in the workflow 50 and the system use model.

  The reason is that the scheduler 21 submits the job 51 by the same means as the normal workflow 50. This is also because the debug server 22 can transmit the debug command input from the client terminal 11 to the resource device 30 selected for executing the job 51 and execute it in each.

  Next, a second embodiment of the present invention will be described with reference to FIGS. FIG. 10 shows a mode table 70 provided in the management apparatus 20. The mode table 70 includes a job ID 71 corresponding to each job 51 and a valid mode 72 that is a designated value of a mode in which the job 51 is executed.

  The valid mode 72 defines for each job 51 whether the job 51 is executed in the normal mode or the debug mode. The workflow 50 can dynamically change the mode in which each job 51 is executed by rewriting the valid mode 72 in the execution process via the scheduler 21. Here, the execution process of the workflow 50 refers to a period during execution of the job 51 belonging to the workflow 50 and a period between execution of the job 51 and another job 51.

  FIG. 11 is a flowchart of the scheduler 21 in the present embodiment. When the workflow 21 is input, the scheduler 21 in this embodiment registers a pair of the job ID 52 and the mode designation 57 of each job 51 in the workflow 50 as a pair of the job ID 71 and the valid mode 72 in the mode table 70 (S11). . Instead of using the mode designation 57, the scheduler 21 may initially set all the valid modes 72 to the designation of the normal mode.

  When the job 51 in the workflow 50 is scheduled, if the effective mode 72 of the job 51 is the debug mode designation (Y in S16), the scheduler 21 activates the debug server 22 (S17). If the effective mode 72 of the job 51 is designated as the normal mode (N in S16), the scheduler 21 designates the normal mode to the agent 33 of the resource device 30 and transmits an activation request for the program 53 (S1B). . Here, the scheduler 21 scans the mode table 70 and refers to the valid mode 72 corresponding to the job ID 71 that matches the job ID 52 of the job 51 being processed.

  In addition, the scheduler 21 of the present embodiment performs calculations and comparisons based on the flow description 59 after the job 51 ends. At this time, a value can be set in the valid mode 72 (S1A). That is, the flow description 59 can include a description for setting a value in the valid mode 72.

  The other steps in FIG. 11 are the same as those in FIG. 4 and will not be described here.

  In the present embodiment, the user can flexibly set debug execution conditions. For example, when the repeatedly executed job 51 is abnormally terminated after being executed a specific number of times, it is possible to perform operations such as executing in the debug mode only after execution of the specific number of times.

  The reason why the debug execution condition can be set flexibly is that the scheduler 21 determines the execution mode of the program 53 based on the mode table 70 and the mode table 70 can be rewritten in the course of executing the workflow 50.

It is a figure which shows the whole structure of a management system. It is a figure which shows the structure of a workflow. 3 is a diagram showing a configuration of a command storage unit 40. FIG. It is a flowchart of a scheduler. It is a flowchart (1) of a debug server. It is a flowchart (2) of a debug server. It is a flowchart of an agent. It is a flowchart of a debugger. It is a figure which shows the whole structure of a management apparatus. It is a figure which shows the structure of the mode table | surface of 2nd Embodiment. It is a flowchart of the scheduler of 2nd Embodiment.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 Management system 11 Client terminal 20 Management apparatus 21 Scheduler 22 Debug server 23 Management program 30 Resource apparatus 31 Debugger 32 User process 33 Agent 40 Command storage part 41 Job ID
42 Command character string 50 Workflow 51 Job 52 Job ID
53 Program 54 Input file 55 Output file 56 Resource requirement 57 Mode specification 59 Flow description 70 Mode table 71 Job ID
72 Effective mode

Claims (16)

A management apparatus that starts a program for a first job in a workflow in a debug mode and starts a program for a second job in the workflow in a normal mode. The management apparatus according to claim 1, wherein the first job program and the designation of the debug mode are transmitted to a resource device that executes the first job program in the debug mode. The management apparatus according to claim 2, wherein the resource apparatus is selected from a plurality of resource apparatuses based on a resource requirement of the first job. A command storage unit for storing debug commands is provided.
The program for the first job is activated a plurality of times in the workflow, and the debug command is acquired from the command storage unit and transmitted to the resource device that executes the debug command for each activation. Item 3. The management device according to Item 3. The management apparatus according to claim 4, wherein starting the program of the first job in a debug mode or starting the program of the second job in a normal mode is determined in the execution process of the workflow. A management system comprising the management device according to claim 3 and the plurality of resource devices. On the computer,
A management program for starting a program for a first job in a workflow in a debug mode and executing a process for starting a program for a second job in the workflow in a normal mode. In the computer,
8. The management program according to claim 7, wherein the first job program and the debug mode designation are transmitted to a resource device that executes the first job program in the debug mode. In the computer,
9. The management program according to claim 8, wherein the resource device is selected from a plurality of resource devices based on a resource requirement of the first job. In the computer having a command storage unit for storing debug commands,
A process of starting the program of the first job a plurality of times in the workflow and acquiring the debug command from the command storage unit and transmitting it to the resource device that executes the debug command for each startup. 10. The management program according to claim 9, wherein the management program is executed. In the computer,
The management program according to claim 10, wherein the first job program is activated in a debug mode or the second job program is activated in a normal mode in a process of executing the workflow. Computer
A management method for starting a program for a first job in a workflow in a debug mode and starting a program for a second job in the workflow in a normal mode. The computer is
13. The management method according to claim 12, wherein the first job program and the debug mode designation are transmitted to a resource apparatus that executes the first job program in the debug mode. The computer is
The management method according to claim 13, wherein the resource device is selected from a plurality of resource devices based on resource requirements of the first job. The computer having a command storage unit for storing debug commands,
The program for the first job is activated a plurality of times in the workflow, and the debug command is acquired from the command storage unit and transmitted to the resource device that executes the debug command for each activation. Item 14. The management method according to Item 14. The computer is
The management method according to claim 15, wherein starting the program of the first job in a debug mode or starting the program of the second job in a normal mode is determined in a process of executing the workflow.

Images