Two Daily jobs should not run at the same time same day

rajeev5582 · Post by **rajeev5582** » 28 Sep 2010 9:02

Hi,

We have come across an issue wherein a daily job ran twice at same day almost the same time due to a rollout.

What i would like to know is...all possible ways to set up this standalone daily job in such a way that they do not run twice same day and if there are two instances the older one gets skipped and the newer job runs?

Thank you in Advance.

nicolas_mulot · Post by **nicolas_mulot** » 28 Sep 2010 10:44

rajeev5582,

A user daily cannot run twice for the same odate under normal circumstances.
The control is performed against the SQL table CMR_UDLAST which contains the name of the user daily and the date of the last execution, and which is normally viewed/updated using the standard utility ctmudlst.
When a daily starts, it checks the date in this table. If the date value is lower than the current date, the process goes on, and the last date is updated to the current odate value. If the date is equal to the current date, the daily aborts with RC=5 and an explicit message “User Daily: already run (LASTRUN = ODAT)”

Since there is only one date entry per user daily, it is not possible, to distinguish whether the daily started, ended of was interrupted (as it is on zOS platform). One can conclude from that that the update on the table is performed at the end of the run. One can conclude as well that your dailies executed simultaneously, I.e. the second occurrence started while the first occurrence was still running.

To avoid this, you may define an exclusive control resource on your daily jobs. In your case, the second occurrence would have waited on control while the first was running, then would have started as soon as the first one finished, then would have failed RC5 as soon as it started, for the reason axplained above.

As a general rule, a control resource should be coded in most of the ctm utilities, including the user dailies, since there is (or was) a general recommendation not to concurrently run utilities which affect the contents of the AJF (ctmudly, ctmorder, ctmcreate …).
In any case, there is no real need to run concurrent user dailies. The OrderId of the ordered jobs are calculated based on the contents of the CMR_LASTNO table. This table contains the last affected ordered: when a need occurs to order a new job, the last used OrderId is read from this table, increased by one, affected to the new job, and updated in the table. As a consequence, this table is a central point of contention for all job order actions. Hence, you will gain nothing at all in terms of performance by running your dailies in parallel. The total elapsed time is always linked directly to the number of jobs which will be ordered at the end of the process, and only depend on ypu system/database performance.

Cheers
Nicolas Mulot

rajeev5582 · Post by **rajeev5582** » 28 Sep 2010 10:51

Thanks for the reply nicolas...but the job wasn't a User daily job...it was a normal .bat job that runs daily at xx:yy time...more help needed...

rajeev5582 · Post by **rajeev5582** » 28 Sep 2010 10:53

Is there any other option other than Control resource and adding condition using a dummy job or from steps tab?

rajeev5582 · Post by **rajeev5582** » 28 Sep 2010 11:00

Any suggestions from Walty/ Phil?????

rajeev5582 · Post by **rajeev5582** » 28 Sep 2010 1:14

Need more help on this logic...Nicholas....

Walty · Post by **Walty** » 28 Sep 2010 2:35

Hi,

In case you have 2 identical jobs (ie: job A=orderid 0xxxA and job A=orderid 0xxxC) scheduled for the same day (ODATE)
job A orderid 0xxxC is submitted before job A orderid 0xxxA because Control-M works in LIFO mode.

If you want to prevent the execution twice and run only the newest:

- Put a 'CONTROL ressource' in exclusive mode in your job (prevent parallel execution)
- Delete IN condition(s) after execution (prevent possible new execution)

In this case, only job A orderid 0xxxC can be executed and job A orderid 0xxxA stay in wait CONDITION

rajeev5582 · Post by **rajeev5582** » 28 Sep 2010 2:57

Thanks for the reply Walty....

Quick question: If we delete the IN condition after the job completes successfully...the next days job will not run..

Walty · Post by **Walty** » 28 Sep 2010 3:48

Hi,

It's depend kind of <date> format you use.

If your job use the IN condition with <date=STAT> it's true, in this case you must create and schedule a DUMMY job to define IN condition with <date=STAT> for the next daily job flow.

If your IN condition use <date=ODAT> it's not a problem because every day your IN conditions are present in daily job flow.