After failing over to the secondary Control-M/Server, jobs are being submitted but any updates from the agent are not being processed by the Control-M/Server. It is seen in the IOALOG that jobs are submitted to the agents. In the agent's daily log, it shows where updates were sent back to the Control-M/Server once a job completes. The ctm_diag_comm and ag_diag_comm output shows that there are no communication issues between the Control-M/Server and Control-M/Agents. When checking the TR logs, it can be seen that there is an issue with the agent's update sent to the Control-M/Server. This can be caused by compatibility being set too low. 1020 13:11:26.207 TR: TR_JOB_check_job: GM_SUBMIT_GetDsect: Agent name field length (99) is too long (in file <SRV home>/status/4475427_1.1603217486_00000) 1020 13:11:26.207 TR: TR_JOB_check_job: CTM6332 -> GM_STATUS_CleanBadDsect : A corrupted status file received from Control-M Agent In the CA logs, the following request can be seen from the Control-M/Enterprise Manager. 1020 13:04:05.172 CA: AASync::calcCtmCompatibilityVersion: Can downgrade CTM/Server compatibility version to: 9.0.00.000 |
This solution should only apply for situations where the customer is using their own custom version of Control-M/Enterprise Manager High Availability. The scenario is that there are two servers: ServerA and ServerB. ServerA has a Control-M/Enterprise Manager and Control-M/Server installed. ServerB has another Control-M/Enterprise Manager (separate install, not secondary) and a secondary Control-M/Server installed. The Control-M/Servers are using HA. However the Control-M/Enterprise Managers are using the BMC local PostgreSQL database, which does not support HA. Instead a custom script has been setup to sync the databases. When a Control-M/Server failover is performed, the "primary'" EM is shutdown and the "secondary" EM is brought up. The solution in this scenario would be to fail over to ServerB and then disable Compatibility Mode in the CCM. |