Enforce unique Job Out-Condition names

All questions about Control-M jobs definitions
Post Reply
User avatar
kshapley
Nouveau
Nouveau
Posts: 2
Joined: 27 Sep 2011 12:00

Enforce unique Job Out-Condition names

Post by kshapley » 19 Dec 2011 6:50

Is there a way or setting in Control-M to enforce unique job out-condition names? We had some jobs that ran that had the same out-condition name that caused downstream jobs to fire off when they were not supposed to because two jobs with differing downstream flows had the same out-condition names

Thanks,

Ken

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

Post by nicolas_mulot » 20 Dec 2011 8:23

kshapley,

Defining and enforcing naming standards is a job by itself, and no standard utility is provided to do that job.

The best you could do is scanning all your definitions, either from EM or from CTM/SV database (in that case, it is a bit late). To do so, you need to develop SQL code, more particularly stored procedures you can run in batch.

I would recommend working at the EM level, though the the structure of the tables is much less flexible than on the CTM/SV side.
For your particular need, you need to consolidate tables DEF_VER_LNKI_P, DEF_VER_LNKO_P and DEF_VER_DO_COND using SQL procedures.

I have implemented such a project in the past, controlling a whole set of naming standards using such procedures. Naming standards were part of a general script, and any error in the controls prevented the table from being uploaded to CTM/SV database.

Cheers
Nicolas Mulot

User avatar
markf
Nouveau
Nouveau
Posts: 134
Joined: 13 Jul 2006 12:00
Location: Switzerland
Contact:

Post by markf » 22 Dec 2011 11:28

The problem is that - sometimes - you do want to use the same cond name. I have a job that relies on an input condition; if the first job doesn't run by 2 a.m. then I run a dummy job to add the condition regardless.

The best way is to use the standard conditions that are generated by the Desktop - we use JOBNAME-TO-JOBNAME as a standard and that should minimise errors. Also, deleting the input condition once the triggered job has completed is good practice.

User avatar
GrahamH
Nouveau
Nouveau
Posts: 30
Joined: 20 Jan 2006 12:00

Post by GrahamH » 22 Dec 2011 3:50

You could also use the @TIME variable on the dependency which will add the order time to the dependency name.

Just a thought.

User avatar
ThePirate
Nouveau
Nouveau
Posts: 61
Joined: 04 Feb 2008 12:00
Location: Cleveland, OH

Post by ThePirate » 23 Dec 2011 12:36

You could also use a simple "OR between all conditions" on the Conditions tab at the "IN Conditions Relationship:" by having a condition from the "Real" job and the "Dummy" job.

Post Reply