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
Enforce unique Job Out-Condition names
- nicolas_mulot
- Nouveau
- Posts: 149
- Joined: 07 Jan 2010 12:00
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
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
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.
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.