Control-M/Enterprise Manager -The following alert is displayed after starting a Control-M/Server: The machine's time zone configuration seems to be wrong.Process will use a simple time zone of xx seconds from UTC

Knowledge Article

Control-M/Enterprise Manager -The following alert is displayed after starting a Control-M/Server: The machine's time zone configuration seems to be wrong.Process will use a simple time zone of xx seconds from UTC
Control-M/Enterprise Manager -The following alert is displayed after starting a Control-M/Server: The machine's time zone configuration seems to be wrong. Process will use a simple time zone of xx seconds from UTC
Control-M/Server for UNIX and Microsoft Windows
Control-M/Server for UNIX and Microsoft Windows
Control-M/Server for UNIX and Microsoft Windows

After the initialization of a Control-M/Server, the Control-M/Enterprise Manager GUI will display the following notification:

It appears that the time zone configuration of the machine is incorrect. As a temporary solution, the process will implement a basic time zone that is xx seconds away from Coordinated Universal Time (UTC).

It is possible that the NS or CE logs will exhibit an error message along with numerous repeated time zone notifications, which will be expressed in the following manner: "java.time.DateTimeException: Invalid ID for region-based ZoneId, invalid format:"
It has been discovered that the java timezone settings bundled with the JRE of the Control-M Server are the cause of the issue. We recommend that you consult with your System Administrator to address this matter

The reason for this alert is that the time zone configuration of the machine does not match the time zone configuration of the Java installed on the machine. This discrepancy can cause scheduling problems since Control-M/Server uses both Java processes and regular binaries that use the machine's time zone configuration. To troubleshoot this issue, the Control-M/Server needs to be started in debug mode. Follow these steps:

  1.     Stop the Control-M/Server Configuration Agent and Control-M/Server by executing the following commands: 
    •     shut_ca
    •     shut_ctm.
  2.     Start the Control-M/Server in debug mode by running this command:
    •     start_ctm -d4.
  3.     Wait for a minute, then stop the debug mode by running this command:
    •     dbglvl ALL 0.
  4.     Restart the Configuration Agent by running the command:
    •     start_ca.


After performing these steps, check the CE* files in the ~/ctm_server/proclog/ directory for a line similar to the example below:
"Default time zone Europe/Paris is not synched with machine's: C: 1351382400 2012/10/28 01:00 DST0. Java: 1351382400 2012/10/28 02:00 DST1."
In this example, you can see that there is a discrepancy between the machine's time zone and Java's time zone settings. The warning is issued because the machine's time zone will change from daylight savings to normal time at 1:00 am on 28-OCT whereas Java's time zone will change at 2:00 am.

To resolve the issue, contact your System Administrator to verify the machine's time zone configuration settings. For additional information on how Java handles DST, refer to this link: https://www.infoworld.com/article/2076192/set-your-java-clocks-for-the-new-dst.html

To ensure that BMC provided JRE has the correct DST timezone definitions, follow this procedure. If the definitions need to be updated, do so promptly. Failure to update these definitions may lead to a 1-hour shift in the current time, causing jobs to run at the wrong time.

To ensure your BMC-provided Java has the latest changes for Daylight Savings Time support, follow these steps:
Execute this procedure on every account where BMC JRE is present. It should be executed every time there is a change in the timezone definition, especially when there is a change in DST from one day to another.

For the AIX platform, follow these steps:

  1.     Login to the Control-M/Server account.
  2.     For safety, backup the ctm_server/JRE_64 directory.
  3.     Download the latest version of "tzupdater.jar" from the Oracle website and copy it to the ctm_server/JRE_64 directory.
  4.     Create a local directory for JTZU in the JAVA_HOME path.
  5.     Download the latest zip file from the IBM website for JTZU (Java SDK Time Zone Update Utility) and extract the files using the jar utility or unzip commands.
  6.     Change file permissions to allow JTZU to run from the command line.
  7.     Edit the runjtzuenv.sh file and ensure that JAVA_HOME is set to the correct path of the ctm_server in your environment.
  8.     Stop the Control-M/CA and Control-M/Server.
  9.     Run runjtzu.sh. The first execution will only create a list of JREs available for patching on SDKList.txt.
  10.     Edit the runjtzuenv.sh file and change DISCOVERYONLY to false.
  11.     Run runjtzu.sh again. The second execution will effectively update the Java time zone definitions. Any errors can be found in LogFile.log.
  12.     Check if new DST definitions were loaded for Control-M/Server by running "./java -jar tzupdater.jar -V" in the ctm_server/JRE/bin directory.
  13.     Make sure JRE tzdata is with the current year date.
  14.     Start the Control-M/Server and Control-M/CA.
  15.     Verify AIX timezone definitions by running "zdump -v America/Sao_Paulo | grep [year]" and checking if the start and end dates correspond to the designated start and stop of DST. Consult your system admin if necessary.
For the Unix/Linux platforms, except AIX follow these steps:
  1. Log in to your Control-M/Server account.
  2. Backup the ctm_server/JRE directory to safeguard your data.
  3. Download the following files:
    • The latest version of the "tzupdater" tool from https://www.oracle.com/java/technologies/javase-tzupdater-downloads.html.
    • The latest "tzdataXXX.gz" from https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz.
      • Note: Both files must be placed in the Control-M/Server home directory where the "installed-version.txt" file is located.
  4. Extract the "tzupdater" tool. In the Control-M/Server's home directory, you should have the following files:
    • tzupdater.jar
    • tzdata-latest.tar.gz
  5. Navigate to the directory "ctm_server/JRE/bin" by running the following command:
    • cd ctm_server/JRE/bin
  6. Run the following command:
    • ./java -jar <Control-M/Server home>/tzupdater.jar -l file:///<Control-M/Server home>/tzdata-latest.tar.gz
      • Example: ./java -jar /home/ctmsrv/tzupdater.jar -l file:///home/ctmsrv/tzdata-latest.tar.gz
  7. Validate that the update has been successful by running:
    • ./java -jar <Control-M/Server home>/tzupdater.jar -V
  8. The output should show that you are using the tzdata file for the current year (e.g. tzdata2022c).
  9. Restart Control-M/Server by running the following commands:
    • shut_ca; shut_ctm
    • start_ctm; start_ca
For the Windows platforms, follow these steps:
  1. Create a backup of the "\Program Files\BMC Software\Control-M Server\ctm_server\JRE" directory.
  2. Download the latest version of the "tzupdater" tool from: https://www.oracle.com/java/technologies/javase-tzupdater-downloads.html.
  3. Download the latest "tzdataXXX.gz" from: https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz. Both files must be saved in the "\Program Files\BMC Software\Control-M Server\ctm_server\JRE" directory.
  4. Extract the "tzupdater" tool. After extraction, you should have these two files in the "\Program Files\BMC Software\Control-M Server\ctm_server\JRE" directory: tzupdater.jar and tzdata-latest.tar.gz.
  5. Open a command prompt window with administrator privileges and navigate to the "\Program Files\BMC Software\Control-M Server\ctm_server\JRE" directory using the following command:
    • cd "C:\Program Files\BMC Software\Control-M Server\ctm_server\JRE"
  6. Run the following command:
    • java -jar tzupdater.jar -l file:"C:\Program Files\BMC Software\Control-M Server\ctm_server\JRE\bin\tzdata-latest.tar.gz"
  7. To verify that the update was successful, run this command:
    • java -jar tzupdater.jar -V
  8. If successful, the output should indicate that you are using the tzdata file for the current year (e.g. tzdata2022c).
  9. Finally, restart Control-M/Server. You can do this by executing the following commands:
    • shut_ca
    • shut_ctm
    • start_ctm
    • start_ca
 


Troubleshooting:
1. Getting error msg when verifying or install Java timezone DST files. 
./java -jar /home/ctm918/tzupdater.jar -V
Error parsing configuration
Exception in thread "main" com.sun.tools.tzupdater.TzRuntimeException: java.security.ProviderException: Error parsing configuration
        at com.sun.tools.tzupdater.TimezoneUpdater.main(TimezoneUpdater.java:653)
Most probably this error is caused by the security setting for a give JRE environment. 
the security configurations are stored in  <ctm-home>/JRE/lib/security/java.security" file
The recommended workaround is to
stop the Agent and MFT/AFT 
backup java.security file
replace the file with another version from a different control module such as CM for Database, CM for SAP, etc with the one of AFT/MFT
repeat the procedure above.
restore the java.security back to the MFT/AFT location
restart Agent
 
2. If this is a Solaris environment that has a JRE_64 java directory ($HOME/ctm_server/JRE_64/bin/java), after running the script (./java_bmc_updater.csh from step b6), run ./java -jar tzupdater.jar -V from the JRE_64/bin/java directory. If it does not return JRE tzdata version tzdata2018 or higher, download https://data.iana.org/time-zones/releases/tzdata2018e.tar.gz, then run the command: $HOME/ctm_server/JRE_64/bin/java -jar tzupdater.jar -l file:tzdata2018*.tar.gz.

3. If you get error messages such as below, download https://data.iana.org/time-zones/releases/tzdata2018e.tar.gz and try again. In the command line, specify tzdata2018e.tar.gz  instead of tzdata-latest.tar.gz:
Failed: java.lang.Exception: Failed while parsing file '/tmp/tz.tmp_2/asia' on line 1655 'Rule  Japan   1948    1951    -       Sep     Sat>=8  25:00   0       S'
java.lang.Exception: Failed while parsing file '/tmp/tz.tmp_2/asia' on line 1655 'Rule  Japan   1948    1951    -       Sep     Sat>=8  25:00   0       S'
        at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:377)
        at tools.tzdb.TzdbZoneRulesCompiler.compile(TzdbZoneRulesCompiler.java:191)
        at tools.tzdb.TzdbZoneRulesCompiler.<init>(TzdbZoneRulesCompiler.java:307)
        at com.sun.tools.tzupdater.ExternalModule.compileToJSRBinary(ExternalModule.java:153)
        at com.sun.tools.tzupdater.TimezoneUpdater.run(TimezoneUpdater.java:230)
        at com.sun.tools.tzupdater.TimezoneUpdater.main(TimezoneUpdater.java:634)
Caused by: tools.tzdb.DateTimeException: Invalid value for SecondOfDay value: 90000
        at tools.tzdb.ChronoField.checkValidValue(ChronoField.java:173)
        at tools.tzdb.LocalTime.ofSecondOfDay(LocalTime.java:210)
        at tools.tzdb.TzdbZoneRulesCompiler.parseMonthDayTime(TzdbZoneRulesCompiler.java:475)
        at tools.tzdb.TzdbZoneRulesCompiler.parseRuleLine(TzdbZoneRulesCompiler.java:399)
        at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:354)
 
Run again the command below, verify that the JRE tzdata version is now tzdata2018e or higher
       [Sun/Solaris] <control-m/server home directory>/ctm_server/JRE_64/bin/java -jar tzupdater.jar -V
       [Linux] <control-m/server home directory>/ctm_server/JRE/bin/java -jar tzupdater.jar -V
       [Windows] <control-m/server home directory>\ctm_server\JRE\bin\java -jar tzupdater.jar -V

4. Additional verification of the changes 
  1. View the file C_time_stamps.txt in
[Linux/Sun/Solaris]< control-m/server home directory >/ctm_server/tmp directory
[Windows]< control-m/server home directory >\ctm_server\temp directory
 
Verify that you see the Day light changes at the correct dates and times.
 
For example:
Previous Israel Daylight Saving, on the 2018/10/28, at 2 AM the clocks were turned backwards 1 hour to 1 AM, as seen in the C_time_stamps.txt file
1540674000 2018/10/28 00:00 DST1
1540677600 2018/10/28 01:00 DST1
1540681200 2018/10/28 01:00 DST0
1540684800 2018/10/28 02:00 DST0
 
  1. Look in the CE log for the following similar messages (in debug level 0):
1022_15:29:30.893,Default time zone America/Sao_Paulo is not synched with machine's: C: 1540227600
2018/10/22 14:00 DST0. Java: 1540227600 2018/10/22 15:00 DST1.", [INFO], T@1, T:main, , com.bmc.ctms.common.TimeZoneSynchronizer, TimeZoneSynchronizer::fullSync, ,
 
1022_15:29:31.702, "No matching time zone was found", [WARNING], T@1, T:main, , com.bmc.ctms.common.TimeZoneSynchronizer, TimeZoneSynchronizer::locateMatchingTz, ,
 
1022_15:29:31.702, "The machine's time zone configuration seems to be wrong.", [WARNING], T@1, T:main, , com.bmc.ctms.common.TimeZoneSynchronizer, TimeZoneSynchronizer::fullSync, ,
 
1022_15:29:31.703, "Process will use a simple time zone (CTM-03:00) of -10800 seconds from UTC", [INFO], T@1, T:main, , com.bmc.ctms.common.TimeZoneSynchronizer, TimeZoneSynchronizer::fullSync, ,
 
If the java was updated with the correct DST change, you will not see these messages.
The Control-M/Server CE process (java) will align with the C code times.   


 
Note.: If the problem persist, it means that machine TZ is wrong, to fix it, execute the command as root:
  
yum update tzdata

Or install it with command:


yum install tzdata
Control-M/Server for UNIX and Microsoft Windows
Control-M/Server for UNIX and Microsoft Windows
Control-M/Server for UNIX and Microsoft Windows
Control-M/Server for UNIX and Microsoft Windows
Control-M/Server for UNIX and Microsoft Windows
Control-M/Server for UNIX and Microsoft Windows
Attachment(s):