Control-M Time Zone problem

Tammy · Post by **Tammy** » 07 Oct 2013 9:40

We recently moved one of our Control-M servers from a location that was in MST to a location that's in CST. Ever since, we've had trouble with jobs that specify a 'Submit between' time with a Time Zone whose time is earlier than CST time AND the 'Submit TO' time does not specify a time value. These jobs run as soon as they scan in with new day rather than waiting for it's submit time to arrive. Jobs that execute in CST or EST time do not have this problem. We are also using a unique Time Zone for Arizona (AZT) that we've defined in Control-M server, EM and our workstations. (We are using Control-M v7.) We followed BMCs recommendation and installed FP5 of Control-M server, moved the AZT timezone definition to the bottom of the TimeZone.dat file and added '-odate_option run_date' to our ctmudly command but have the same results. Because AZT does not observe Daylight Savings as EST, MST, CST do, we will have to adjust our TO times twice a year as a workaround. We're hoping to prevent that.
Has anyone else seen this situation? Are you scheduling jobs that use multiple timezones and some observe DST and others do not?

Walty · Post by **Walty** » 08 Oct 2013 7:40

Hi Tammy,

In the past i encountered one similar case (Time not specify correctly) caused by syntax of <ctmudly>

Have you tried to use this syntax:

ctmudly -DAILY_NAME <your_daily> -ODATE <your_date> -ODATE_OPTION RUN_DATE (work correctly if you specify -DAILY_NAME)

This syntax is not correct (Time is not correct)

ctmudly <your_daily> -ODATE <your_date> -ODATE_OPTION RUN_DATE

Tammy · Post by **Tammy** » 09 Oct 2013 11:36

Thanks for the suggestion Walty. The command I was using is
ctmudly MOO -odate_option run_date
Then I changed it to
ctmudly MOO -odate ODAT -odate_option run_date
We are getting the same results with both commands. We do have jobs scheduled with CST, EST, MST and AZT time zones and the only ones that are giving us a problem are the ones where the time in their time zone is earlier than our Control-M server time (CST). I can change it to the actual ODAT date and see what that does tomorrow when my user daily job executes. I've also opened a case with BMC and am hoping they can figure this out before the DST changes occur in Nov.