Multiple jobs for same program are not overlapping or affecting each other?

[sayani_sarkar]

We have a custom program in ECC that sends email notifications for different invoice statuses and updates the statuses in a custom table for each invoice, inside the program. This custom program needs to be scheduled multiple times such that the multiple job runs might overlap with each other.

How can we ensure that the multiple job runs for the same program are not overlapping with each other and stopping the processing of any of the multiple job runs?

[sayani_sarkar]

We have a custom program in ECC that sends email notifications for different invoice statuses and updates the statuses in a custom table for each invoice, inside the program. This custom program needs to be scheduled multiple times such that the multiple job runs might overlap with each other.

How can we ensure that the multiple job runs for the same program are not overlapping with each other and stopping the processing of any of the multiple job runs?

[michal_majer]

You should use Enqueue / Dequeue, to be sure that only one program access to selected data. With enqueue, data is blocked in the current process. If another program will try to access same data we can wait when other program ends processing or wait in the queue.

[sayani_sarkar]

Thank you for your answer.
If we are using a lock object for the custom table that is updated by the job, we can use enqueue/dequeue only during custom table updation right?
Also we need to specify in the program code how much time is needed to wait if it finds the table locked?

[Sandra_Rossi]

If a job B is started while a job A is still running, I think the job B should stop immediately, as the job A should control whether there is still some data to process before ending (and process it if any).

You can enqueue/dequeue as you wish, when you wish. It's not related to the database update. It's only related to the "update task" if you use one (CALL FUNCTION IN UPDATE TASK). You can use a lock object even on a DDIC structure.

[Former Member]

For this type of thing I tend to enqueue the TRDIR entry for the actual program and check that during initialisation.

[sayani_sarkar]

Hi Kiran,

We currently have Job1 already scheduled daily at an hourly frequency. Job2 and Job3 for the same program will be scheduled twice and once a week respectively.
If the jobs will be scheduled as event triggered jobs, such that when the job1 finishes the job2 or job3 is triggered, this will cause an overlap again when the job1 is triggered while the job2 or job3 is still running because the job1 runs hourly.
How can we ensure that one job is not overlapping and stopping any other job?

[kiran_k8]

Sayani,

"this will cause an overlap again when the job1 is triggered while the job2 or job3 is still running because the job1 runs hourly."

Job1 will not be triggered if job2 or Job3 is is under execution. At any point of time only one job will run and make the suceessive jobs to wait for the preceeding job to get completed.

You can use EVENT and test in DEV to get the look and feel.

K.Kiran

[kiran_k8]

As my reply is voted down,willing to learn on why EVENT mechanism is not a valid solution.

Thanks,

K.Kiran.

[Sandra_Rossi]

A job triggered by an event can be started several times at the same time; events do not prevent several instances of the same job.

PS: only a job defined with a "predecessor job" is guaranted to not run during another job, as it will start right after the predecessor job has finished (but, as the predecessor feature requires that the second job is defined before the first job is released, then it does not match the OP's question).

[pokrakam]

Another technique is to have each job reschedule itself. You would have to build your monthly/weekly variants into your rescheduling code.

[Former Member]

Or use a table....

[Sandra_Rossi]

It's just a like/not like : 1) It doesn't mean your answer is wrong; people can like an answer, even if the answer is not valid 2) People are not required to explain why they like/don't like. 3) A like/not like is just a trend of "something".