Adhoc Job and Load Job attempt < 2

All questions about Control-M jobs definitions
Post Reply
User avatar
det72004
Nouveau
Nouveau
Posts: 12
Joined: 28 Oct 2008 12:00

Adhoc Job and Load Job attempt < 2

Post by det72004 » 28 Sep 2010 4:08

Hi,

I got couple of questions:
1) Load Job attempt < 2

How to handle in Control-M that a job will automatically restart by itself if its execute job attempt < 2?

Meaning, we're expecting a job to fail due to some DB locking issues (for example) and we want it to automatically restart if execute job attempt < 2.

Right now, the 2 options I see to handle this are:
- Define rules on how Operations team handle specific jobs. In this case, they'll manually restart the job if load job attempt is less than 2.
- Handle in shell script.

2) Adhoc job

Say the normal flow is:

Job_Start triggers Job2 and Job3.
Job 2 and Job 3 triggers Job_End


If in case, for a specific run, I only want Job_Start to trigger Job2 and that Job_End will only be dependent on Job2. How can we automatically do this?

Right now, the only option I see to handle this is by creating separate job flows and just run which one is applicable for a specific time. But, just some thought, what if we have more than 50 scenarios? Creating 50 separate job flows would be a lot of hassle.

Hope to hear from the experts.

Thanks!

User avatar
det72004
Nouveau
Nouveau
Posts: 12
Joined: 28 Oct 2008 12:00

Post by det72004 » 28 Sep 2010 10:49

almost whole day already... anyone?

User avatar
nicolas_mulot
Nouveau
Nouveau
Posts: 149
Joined: 07 Jan 2010 12:00

Post by nicolas_mulot » 28 Sep 2010 11:15

det72004,

Some issues have been left without reply for ages, be patient.

1) Load Job attempt < 2
The issue is not that clear or too clear.
The first idea is to do an automatic rerun using the Steps statements as follows:
ON STMT * CODE <your>
DO Rerun

.. and controlling the max rerun using the “maxrerun” field in the “Execution” tab.
Did you check that? In case you did, pls provide further details.

2) Adhoc job
The issue cannot be replied until we know exactly how you order your scenario.

If the order date for Job2 and Job3 are inconsistent in the job definitions, then you have several solutions:

The first one consists in defining your scenario within a Scheduling group. Specifying “Adjust Condition” in the “Execution” tab of the SG definition (ctm 6.4 – should be in the General tab in 6.3) will automatically address your point. In taht situation, the links will be adjusted automatically at order time, i.e. the link between Job3 and Job_End will be removed from the JobEnd definition if Job3 is not ordered.

As a compliment to that solution, the effect of the ctm server parameter CTM_GROUP_ADJUST_DUMMY will be that Job3 will be ordered as a dummy job when it is not orderable, and JobEnd will still depend of Job2 and Job3, while Job3 is not actually executed, being dummy for that ODATE.

The second one is to rely on maybe conditions.
The principle is that those conditions which are not set by any ordered job (in your case Job3_to_JobEnd) can be identified and stored in a file. This action is performed by the standard utility ctmldnrs, the calling parameter being far that case –CALCCOND.
Once a condition has been identified as manual, it can be added (in mass together with other ones) using the same ctmldnrs utility, the calling parameter then being –LOAD, and the scope being limited by a name or a mask of condition names (e.g.: Job3*) .

This last solution is the only working one in case your jobs are not defined in a Scheduling Group, or in the same Scheduling Group, or if you order your jobs manually, and one by one, let’s say JobEnd, then Job_Start, then Job2 then nothing.
The flow of ctmldnrs –CALCCOND / – ctmldnrs –LOAD might be run any time, several times a day.

In your case, it should be run when you are sure that Job3 has no more chance to be ordered today. Job3 may be ordered or not (hence the name of “maybe jobs” commonly used), and you must have an idea of a time in the day where it has no more chances to be ordered before setting the Job3_to_JobEnd condition (hence the name of “maybe conditions” commonly used).

This sequence can be run every day. If Job3 has by chance been ordered prior to the ctmldnrs sequence, the condition will not be covered by the ctmldnrs sequence, and your JobEnd will probably have finished executing long before you run the sequence.

Of course, you should give your conditions a specific prefix which will simplify the management of these conditions during the –LOAD stage, and which would avoid negative side effects on the rest of your ctm workload.

Good luck and consult the manuals for further explainations.

Nicolas_Mulot

User avatar
det72004
Nouveau
Nouveau
Posts: 12
Joined: 28 Oct 2008 12:00

Post by det72004 » 28 Sep 2010 11:43

Hi Nicolas,

Quick question on #1:
The Steps statements, this DO Rerun... does this handle the condition like if the job fails Do Rerun as long as job attempt rerun < 2?

Basically, the idea here is if the job is failing... it should automatically attempt to rerun itself up to 2 times. If for the 2nd rerun attempt it still fails, then don't re-run anymore.

User avatar
nicolas_mulot
Nouveau
Nouveau
Posts: 149
Joined: 07 Jan 2010 12:00

Post by nicolas_mulot » 28 Sep 2010 12:19

This is exactly it.

1st run: notok --> rerun once
2nd run: notok --> rerun twice
3rd run: notok --> do not rerun and leave RED - Notok

User avatar
det72004
Nouveau
Nouveau
Posts: 12
Joined: 28 Oct 2008 12:00

Post by det72004 » 29 Sep 2010 3:32

Hi Nicholas,

Great replies, really gave me an idea on how to handle those cases.
Although, I need to check the manuals for the actual details on implementing it especially on the ctmldnrs utility.

Thank a lot!

User avatar
nicolas_mulot
Nouveau
Nouveau
Posts: 149
Joined: 07 Jan 2010 12:00

Post by nicolas_mulot » 29 Sep 2010 8:09

Yes, good idea.
Read the manual. I have to admit it is not always that clear if you start from scratch.
Coem back to that forum if you need further explainations or provide more details on your case.

Cheers

Post Reply