SYSTEM AND METHOD FOR MODIFYING EXECUTION OF SCRIPTS FOR A JOB SCHEDULER USING DEONTIC LOGIC

• US 20100211815A1
• Filed: 01/11/2010
• Published: 08/19/2010
• Est. Priority Date: 01/09/2009
• Status: Active Grant

• Current Assignee: CA, Inc. (d/b/a CA Technologies) (Broadcom, Inc.)
• Original Assignee: Computer Associates Think Inc. (Broadcom, Inc.)
• Inventors: Steele, Jody, Banger, Colin, Mankovskii, Serguei, Gray, Tomas
• Granted Patent: US 8,266,477 B2
• Time in Patent Office: Days
• US Class Current: 714/2
• CPC Class Codes: G06F 11/0709 in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
• CPC Class Codes: G06F 11/0715 in a system implementing multitasking multitasking per se G06F9/46
• CPC Class Codes: G06F 11/0748 in a remote unit communicating with a single-box computer node experiencing an error/fault remote testing G06F11/2294
• CPC Class Codes: G06F 11/0793 Remedial or corrective actions recovery from an exception in an instruction pipeline G06F9/3861; by retry G06F11/1402; for recovering from a failure of a protocol instance or entity H04L69/40
• CPC Class Codes: G06F 11/1438 Restarting or rejuvenating
• CPC Class Codes: G06F 11/1482 by means of middleware or OS functionality

Abstract

A system and method for modifying execution scripts associated with a job scheduler may include monitoring for the execution of a task to determine when the task has failed. Details of the failed task may be identified and used to attempt recovery from the task failure. After initiating any recovery tasks, execution of the recovery tasks may be monitored, and one or more supplementary recovery tasks may be identified and executed, or the original task may be rerun at an appropriate execution point based on the initial point of failure. Thus, when a task has failed, an iterative process may begin where various effects of the failed task are attempted to be rolled back, and depending on the success of the rollback, the initial task can be rerun at the point of failure, or further recovery tasks may be executed.

Claims

1. A system for modifying execution of one or more scripts for a job scheduler using deontic logic, comprising:

a job scheduler configured to execute a schedule that includes at least one task having a goal associated therewith, the goal further having a deontic modality associated therewith, wherein the job scheduler creates one or more event logs containing information relating to the execution of the at least one task; and

a rollback and rerun supervisor communicatively coupled to the job scheduler, wherein the rollback and rerun supervisor is configured to;

access the one or more event logs to determine whether the at least one task succeeded or failed based on whether the goal has been achieved in a manner consistent with the deontic modality;

determine at least one deontic modality associated with recovering from failure of the task if the rollback and rerun supervisor determines that the task failed to achieve the goal in a manner consistent with the deontic modality for the goal; and

load a recovery script to the job scheduler based on the deontic modality associated with recovering from failure of the task, wherein the recovery script loaded to the job scheduler includes a task description designed to achieve the goal in a manner consistent with the deontic modality.

2. The system of claim 1, wherein the goal has an Obliged deontic modality associated therewith, wherein the rollback and rerun supervisor is further configured to:

determine that the task succeeded if the goal has been achieved; and

determine that the task failed if the goal has not been achieved.

3. The system of claim 2, wherein the task description includes one or more tasks designed to achieve the goal that has not been achieved.

4. The system of claim 1, wherein the goal has an Interdicted deontic modality associated therewith, wherein the rollback and rerun supervisor is further configured to:

determine that the task succeeded if the goal has not been achieved; and

determine that the task failed if the goal has been achieved.

5. The system of claim 4, wherein the task description includes one or more tasks designed to rollback the goal that has been achieved.

6. The system of claim 1, wherein the goal has a Permitted deontic modality associated therewith, wherein the rollback and rerun supervisor is further configured to determine that the task has succeeded whether or not the goal has been achieved.

7. The system of claim 1, wherein the deontic modality associated with recovering from failure of the task includes a rollback deontic modality and a rerun deontic modality.

8. The system of claim 7, wherein the deontic modality associated with recovering from failure of the task includes a rollback deontic modality and a rerun deontic modality.

9. The system of claim 8, wherein the rollback deontic modality indicates whether rolling back the failed task is Obliged, Permitted, or Interdicted.

10. The system of claim 8, wherein the rerun deontic modality indicates whether rerunning the failed task is Obliged, Permitted, or Interdicted.

11. The system of claim 1, wherein the rollback and rerun supervisor is further configured to cancel one or more upstream goals associated with the schedule if the event logs indicate that the task has completed and that the task has been cancelled.

12. A method of executing a schedule that includes a plurality of tasks, comprising:

providing a schedule for executing each of the plurality of tasks;

initiating execution for one of the plurality of tasks according the schedule, wherein the executed task has a goal and a deontic modality relating to the goal;

generating an execution event log relating to the execution of the task, wherein the execution event log contains information relating to whether the goal has been achieved based on an execution status of the task; and

attempting to identify a recovery schedule to roll back the task if the execution event log indicates that the goal has been achieved and the deontic modality indicates that the goal is Interdicted, wherein the recovery schedule includes at least one recovery task having a goal to rollback the achieved goal, and wherein the goal of the recovery task includes an Obliged deontic modality requiring rollback of the achieved goal.

13. The method of claim 12, further comprising:

initiating execution for the at least one recovery task according the recovery schedule;

generating a recovery event log relating to the execution of the at least one recovery task, wherein the recovery event log contains information relating to whether rollback of the achieved goal has been achieved based on an execution status of the recovery task; and

determining whether the recovery schedule has succeeded or failed based on the information contained in the recovery event log.

14. The method of claim 13, further comprising attempting to identify a second recovery schedule to rerun the task if the recovery event log indicates that the recovery schedule has succeeded.

15. The method of claim 12, further comprising attempting to identify a recovery schedule to achieve the goal of the task if the execution event log indicates that the goal has not been achieved and the deontic modality indicates that the goal is Obliged, wherein the recovery schedule includes at least one recovery task having a goal to achieve the Obliged goal.

16. The method of claim 15, further comprising resuming execution of the schedule if the recovery schedule successfully achieves the Obliged goal.

17. A method for modifying execution of one or more scripts for a job scheduler using deontic logic, comprising:

executing a schedule that includes at least one composite task, wherein the composite task includes a plurality of dependent sub-tasks arranged in a predetermined relationship that defines a manner for executing the plurality of dependent sub-tasks;

creating one or more execution event logs containing information relating to the execution of the plurality of dependent sub-tasks; and

determining whether the composite task succeeded or failed based on the information in the execution event logs, wherein the composite task succeeds if the execution event logs indicate that the plurality of dependent sub-tasks completed execution in a manner consistent with the predetermined relationship defined for the plurality of dependent sub-tasks.

18. The method of claim 17, wherein the predetermined relationship includes a sequence relationship that specifies a predetermined order for executing each of the plurality of dependent sub-tasks.

19. The method of claim 17, wherein the predetermined relationship includes a parallel relationship that permits each of the plurality of dependent sub-tasks to be executed in parallel to one another.

20. The method of claim 17, wherein the predetermined relationship includes a fork relationship that only permits one the plurality of dependent sub-tasks to be executed, wherein the first of the plurality of dependent sub-tasks to provide an affirmative signal is selected as the sub-task to be executed.

21. The method of claim 17, wherein the predetermined relationship includes a select relationship that provides a predicate for each of the plurality of dependent sub-tasks, wherein the predicates associated with the plurality of dependent sub-tasks are evaluated in a predetermined order and wherein the first of the plurality of dependent sub-tasks to have a predicate that evaluates to true is selected for execution.

22. The method of claim 17, wherein the predetermined relationship includes a choice relationship that specifies a predetermined order for executing each of the plurality of dependent sub-tasks and a predetermined event for each of the plurality of dependent sub-tasks, wherein a first of the plurality of dependent sub-tasks is initiated according to the predetermined order and wherein initiation of subsequent dependent sub-tasks is based on the predetermined event associated with the first dependent sub-task.