Control M tips & tricks

bullu · Post by **bullu** » 11 Jul 2009 7:04

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

markf · Post by **markf** » 13 Jul 2009 10:13

I'll start the ball rolling -

1. Always 'clean up' input conditions when a job ends ok. This reduces load on the Control-M Server.

markf · Post by **markf** » 13 Jul 2009 10:18

And here's one more -

1. Add a quantitative Resource to all jobs, something like ctm_ok. Then add 1,000 (or whatever) QRs called ctm_ok to your system - that way you can control the maximum number of jobs running and even 'quiesce' the system neatly if needed (by setting the QRs to zero).

Banshee06 · Post by **Banshee06** » 13 Jul 2009 5:33

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

bullu · Post by **bullu** » 13 Jul 2009 6:31

thank you for the tips

I expect more and more... thanks again for your help.

Regards,
Karthik

markf · Post by **markf** » 14 Jul 2009 10:09

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.

markf · Post by **markf** » 17 Jul 2009 5:27

If you put this on the Set panel -

Var Name = HOUR Value = %%SUBSTR %%TIME 1 2
Var Name = MINUTE Value = %%SUBSTR %%TIME 3 2

Then you'll be able to use the variables %%HOUR and %%MINUTR in your jobs.

YOWAL · Post by **YOWAL** » 17 Jul 2009 5:27

you might give an example please?

2. Create a job that will execute the "erase_alerts" to regularly housekeeps old alerts from GAS.

YOWAL · Post by **YOWAL** » 17 Jul 2009 5:45

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

ejtoedtli · Post by **ejtoedtli** » 17 Jul 2009 7:51

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.

ejtoedtli · Post by **ejtoedtli** » 17 Jul 2009 7:57

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

markf · Post by **markf** » 21 Jul 2009 1:41

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).