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

Version 123
    Share This:

    This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.


    PRODUCT:

    Control-M/Server for UNIX and Microsoft Windows


    COMPONENT:

    Control-M/Server for UNIX and Microsoft Windows


    APPLIES TO:

    Control-M/Server for UNIX and Microsoft Windows



    PROBLEM:

     

    The following alert is displayed in the Control-M/Enterprise Manager GUI 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

    NS or CE logs may have the following error:

    "java.time.DateTimeException: Invalid ID for region-based ZoneId, invalid format: 

     


    CAUSE:

    The problem has been identified with the java timezone settings included with the JRE of the Control-M Server, please ask your System Admin to look at it.


    SOLUTION:

     

    Legacy ID:KA368585

      

    This alert is being issued because the machine's time zone configuration does not match the time zone configuration of the Java installed on this machine.
    Since Control-M/Server uses both Java processes and regular binaries that use the machine's timezone configuration, such a discrepancy may lead to scheduling problems, therefore the alert is issued to warn the user.

      

    To find out why the alert is issued, start the Control-M/Server in debug mode:

      

    1. Stop the Control-M/Server Configuration Agent and Control-M/Server, by running these commands:
    shut_ca
    shut_ctm

      

    2. Start the Control-M/Server in debug mode, by running this command:
    start_ctm -d4

      

    3. Wait a minute then stop debug, by running this command:
    dbglvl ALL 0

      

    4. Restart the Configuration Agent:
    start_ca

      

    Now in the current CE* files from the ~/ctm_server/proclog/ directory, you will find a line similar to this one:

      

    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 according to Java, the timezone is Europe/Paris. And this timezone will change from daylight savings to normal time on 28/10 at 02:00am.
    But according to the machine's timezone, this change will take place at 28/10 at 01:00am. This discrepancy (2am vs 1am) is the reason for the warning.

      

    Contact your System Administrator to check the machine's timezone configuration settings.
    Additional information on Java handling of DST can be found at 
    https://www.javaworld.com/article/2076192/java-se/set-your-java-clocks-for-the-new-dst.html
     

      

    The following procedure should be used to verify the DST timezone definitions in BMC provided JRE and if needed the definitions need to be updated to reflect the new definitions.
    Failure to update the DST timezone definitions will result in 1 hour shift in current time as jobs may run at the wrong time.

    To update to the latest changes for Daylight Savings Time support in BMC provided Java :
    This procedure needs to be executed in every account where BMC JRE resides. This procedure must be executed every time timezone definition changes as in cases where DST changes from one day to another.
     

      
       
    1. Download the latest JAVA timezone definitions for Control-M/Server and install them     
           
      1. Platform: AIX
      2.   
      
      1. Login to Control-M/Server account.  
     
    2. Backup the ctm_server/JRE_64 directory, just for safeguard  
     
    3 . Download the file tzupdater.jar (attached to this article) and copy it to ctm_server/JRE_64.  
     
        Verify if TZ definitions need to be updated:  
          
            cd ctm_server/JRE_64  
            ./java -jar tzupdater.jar -V  
          
        If the output returns tzdata2018e or higher then you have the latest TZ definitions and can SKIP the rest of the procedure  
     
    4. Create a local directory for JTZU in JAVA_HOME path  
     
    5. Download the latest zip file (This will change depending on year.  Ex: ‘jtzu-1.7.18e.zip’ or jtzu-1.7.19c ) from https://developer.ibm.com/javasdk/support/dst/jtzu/ to the JTZU  directory. Use binary transfer mode, where applicable.  
     
    6. Extract the files. Use the jar utility (This may not be found in JAVA_HOME JRE, OS Jar can be used, or just use unzip commands:  
          
        ./jar -xvf jtzu-1.7.18e.zip  
     
    7. Change the file permissions to allow JTZU to run from the command line:  
     
        chmod 755 runjtzu.sh  
     
    8. Edit runjtzuenv.sh file and ensure that the following line is in the file:  
          
        JAVA_HOME=/home/ctm900/ctm_server/JRE_64 (Note that it's a path example. Use the ctm_server path of your environment)  
        NOGUI=true  
        DISCOVERYONLY=true  
          
    9. Stop the Control-M/CA and the Control-M/Server:  
     
        shut_ca; shut_ctm  
          
    10. Run runjtzu.sh - The first execution will ONLY create a list of JREs available for patching on SDKList.txt  
     
    11. Edit runjtzuenv.sh file and change DISCOVERYONLY=false  
          
    12. Run runjtzu.sh - The second execution will effectively update java time zone definitions.  
     
        If there are any errors please see the messages in LogFile.log  
              
            http://www-01.ibm.com/support/docview.wss?uid=swg21250503  
            http://www-01.ibm.com/support/docview.wss?rs=3068&context=SSNVBF&uid=swg21249759  
              
    13. Double check if new DST definitions were loaded for Control-M/Server:  
     
        cd ctm_server/JRE/bin  
        ./java -jar tzupdater.jar -V  
              
            Output:  
            Tzupdater version 2.1.2-b01  
            JRE tzdata version:tzdata2018e  
          
        JRE tzdata MUST be with 2018 date.  
     
    14. Start the Control-M/Server and Control-M/CA:  
     
        start_ctm; start_ca  
     
    15. Finally, verify if AIX timezone definitoons are correct.   
     
        Run: zdump -v America/Sao_Paulo | grep 2018  
     
        Verify that the DST is set correctly:  
            America/Sao_Paulo  Sun Nov  4 02:59:59 2018 UTC = Sat Nov  3 23:59:59 2018 BRT isdst=0  
            America/Sao_Paulo  Sun Nov  4 03:00:00 2018 UTC = Sun Nov  4 01:00:00 2018 BRST isdst=1  
     
        If start and end dates do not correspond to designated start and stop of DST, please consult with you system admin 
       
      b. Platform: Other flavors of UNIX (except AIX) and Linux  
      
      
      1. Login to Control-M/Server account.  
     
    2. Backup the ctm_server/JRE directory, just for safeguard  
     
    3. Download tzdata_bmc.tar.gz (attached to this article) on Control-M/Server home directory.  
     
        It must be placed on Control-M/Server home directory, where resides installed-version.txt file.  
     
    4. Extract tzdata_bmc.tar.gz:  
     
        tar -zxvf tzdata_bmc.tar.gz  
          
    5. Create a checksum file for downloaded tzdata.tar.gz:  
     
        sha512sum tzdata.tar.gz >  tzdata.tar.gz.sha512  
          
    6. Run ./java_bmc_updater.csh  
     
        Follow the script instructions:  
              
            6.1 - The first step will list the JREs that were found and will be updated.  
            6.2 - The second will show the tzdata version of each JRE  
            6.3 - After user confirmation, all java will be updated with the latest timezone definitions  
            6.4 - At the end, tzdata version will be displayed again for confirmation.  
              
    7. Restart Control-M/Server  
          
        shut_ca; shut_ctm  
        start_ctm; start_ca  
          
    8. Run: zdump -v America/Sao_Paulo | grep 2018  
     
        Verify that the DST is set correctly (example for Brazil/San Paulo, follow the same procedure for your timezone):  
            America/Sao_Paulo  Sun Nov  4 02:59:59 2018 UTC = Sat Nov  3 23:59:59 2018 BRT isdst=0  
            America/Sao_Paulo  Sun Nov  4 03:00:00 2018 UTC = Sun Nov  4 01:00:00 2018 BRST isdst=1  
        If start and end dates do not correspond to designated start and stop of DST, please consult with you system admin 
      
    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 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

    3. Additional verification of the changes 
       
        
    1. View the file C_time_stamps.txt in
    2.  
       
       [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):
    2.  
       
       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 Brazil’s DST change – you will not see these messages.  
       If you see these messages – this is OK. 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

     


    Article Number:

    000089101


    Article Type:

    Solutions to a Product Problem



      Looking for additional information?    Search BMC Support  or  Browse Knowledge Articles