Control M tips & tricks
Control M tips & tricks
Hi,
Can somebody list some of the tips & tricks in control M? This should be like a value add like saving CPU utilization, avoiding job failures etc.... waiting for the best ideas and suggestions
Regards,
Karthik
Can somebody list some of the tips & tricks in control M? This should be like a value add like saving CPU utilization, avoiding job failures etc.... waiting for the best ideas and suggestions
Regards,
Karthik
I use Quantitative resources set to 3 to limit only 3 job at time to hit our Oracle Datbase for the jobs that do go against our production database.
And I use the control resources set to exclusive to make sure that oracle jobs that go against the same schemas or tables only run one job against them at a time. You can use this method for other resources such as servers too
And I use the control resources set to exclusive to make sure that oracle jobs that go against the same schemas or tables only run one job against them at a time. You can use this method for other resources such as servers too
Here's another one -
1. Use a naming convention for in/out conditions that that is specific to both in and out jobs. For example, a site I did work at had their output conditions as "Job-acc52_OK" as their output condition format. Problem was that if they deleted this job they had no easy way of knowing what was dependent. I changed this so that all conditions mentioned the dependent job, e.g. Job-acc52_TO_Job-acc71. Any other jobs requiring an input condition from Job-acc52 will need a separate condition. If Job-acc52 gets removed then you will easily be able to track down the impacted jobs.
1. Use a naming convention for in/out conditions that that is specific to both in and out jobs. For example, a site I did work at had their output conditions as "Job-acc52_OK" as their output condition format. Problem was that if they deleted this job they had no easy way of knowing what was dependent. I changed this so that all conditions mentioned the dependent job, e.g. Job-acc52_TO_Job-acc71. Any other jobs requiring an input condition from Job-acc52 will need a separate condition. If Job-acc52 gets removed then you will easily be able to track down the impacted jobs.
Query update job running
1- Execute on console 'p_36 ordeno'
example:
login as: user
user@server's password:
[YOU HAVE NEW MAIL]
server-user [1] p_36 587zw
result = 8781692
2- SQL plus
sqlplus user/password@INSTANCE
3- update CMR_AJF set STATE = '8', OSCOMPSTAT=1, STATUS='Y' where ORDERNO = '7137925';
replace
ORDERNO = '7137925'; ---> result = 8781692
4- commit;
5- exit
I hope that it should serve them
1- Execute on console 'p_36 ordeno'
example:
login as: user
user@server's password:
[YOU HAVE NEW MAIL]
server-user [1] p_36 587zw
result = 8781692
2- SQL plus
sqlplus user/password@INSTANCE
3- update CMR_AJF set STATE = '8', OSCOMPSTAT=1, STATUS='Y' where ORDERNO = '7137925';
replace
ORDERNO = '7137925'; ---> result = 8781692
4- commit;
5- exit
I hope that it should serve them
Our company uses a program that was written in-house several years ago for deleting alerts.
When we converted to 6.3 we discovered that the GAS need to be bounced after the alerts are deleted. We execute the following command in a job after the alerts are cleaned. (our names removed).
ecs ctl -pf <pwd> pwdfile -C GAS -name <name> -cmdstr "REFRESH"
We run this every day at 02:00am.
When we converted to 6.3 we discovered that the GAS need to be bounced after the alerts are deleted. We execute the following command in a job after the alerts are cleaned. (our names removed).
ecs ctl -pf <pwd> pwdfile -C GAS -name <name> -cmdstr "REFRESH"
We run this every day at 02:00am.
We also cleanup our prerequisite conditions every day. We delete conditions > 3 days old and less than 10 days old. We are running Control-M 6.3 on HPUX. We have a command job that executes the following command:
ctmcontb -DELETEFROM "*" %%A %%B
On the SET tab we have the following:
B %%CALCDATE %%DATE -3
A %%CALCDATE %%DATE -10
B %%SUBSTR %%B 3 4
A %%SUBSTR %%A 3 4
ctmcontb -DELETEFROM "*" %%A %%B
On the SET tab we have the following:
B %%CALCDATE %%DATE -3
A %%CALCDATE %%DATE -10
B %%SUBSTR %%B 3 4
A %%SUBSTR %%A 3 4
Killing long running jobs automatically -
1. Set up a 'shout' destination that maps to a 'p' (for program) on the Control-M Server.
2. On Unix your shout destination script would be something like this -
#! /bin/csh
ctmkilljob -ORDERID $2 &
ctmshout -ORDERID $2 -USER ECS -MESSAGE "Long running job killed" -SEVERITY R &
The first line does the cancel, the second line will send an alert to the ECS console.
3. On the Post Processing panel put this destination in the 'to' field and (importantly) have the message field as just %%ORDERID - then fill in the 'when' and 'param' fields as desired (e.g. Exectime & >010 will mean that your job gets cancelled if it runs longer than 10 minutes).
1. Set up a 'shout' destination that maps to a 'p' (for program) on the Control-M Server.
2. On Unix your shout destination script would be something like this -
#! /bin/csh
ctmkilljob -ORDERID $2 &
ctmshout -ORDERID $2 -USER ECS -MESSAGE "Long running job killed" -SEVERITY R &
The first line does the cancel, the second line will send an alert to the ECS console.
3. On the Post Processing panel put this destination in the 'to' field and (importantly) have the message field as just %%ORDERID - then fill in the 'when' and 'param' fields as desired (e.g. Exectime & >010 will mean that your job gets cancelled if it runs longer than 10 minutes).