Automic Server becomes unresponsive after TZ attribute on a schedule is changed


Article ID: 140641


Updated On:


CA Automic Workload Automation - Automation Engine CA Automic One Automation CA Automic Operations Manager CA Automic Oracle


After modifications to a timezone attribute on a schedule (JSCH), the system becomes unresponsive. It will not respond with either a warm or cold start.

Modification to the timezone attribute can include importing a schedule with an incorrect or non-existent timezone which does not exist in the same client.

In some instances, the schedule objects are stuck in preparing status (Status =1300) 


This can occur when:

- A JSCH has a timezone that is not within the client AND

- There is no timezone defined within the client AND

- There is no timezone defined within the system

This is due to an unexpected behavior under review for future resolution.


Release : 12.2, 12.3



To pre-emptively workaround this issue, add a timezone on the client. General processes without a timezone run in UTC, so the addition of UTC should not change any behavior present within the system. 

If you think you are encountering this issue and the system is unresponsive, bring down all processes, set tcp/ip=2, db=3 in the ucsrv.ini and start one process. Send the log and trace into support via a ticket. 

This has included fixes in the following versions:

Automation Engine 12.3.2
Automation Engine 12.3.4