PARSEC Technical Information

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Why did the system time change in the wrong month? ======

There are a variety of reasons that may explain this situation and before we discuss the other possibilities, we're going to explore a change that the US Congress made to the rules.  In the Energy Policy Act of 2005((1 Energy Policy Act of 2005: https://en.wikipedia.org/wiki/Energy_Policy_Act_of_2005)), the US Congress agreed to change when the semi-annual time changes would occur, starting January 1, 2007.  

Prior to that change, the  Public Utility Holding Company Act of 1935((2 Public Utility Holding Company Act of 1935: https://en.wikipedia.org/wiki/Public_Utility_Holding_Company_Act_of_1935)) dictated that time would change within the US as follows:  The first Sunday of April at 2 a.m and the final Sunday of October at 2 a.m.  

After the change, the rules changed to to the second Sunday of March at 2 a.m. and the first Sunday of November at 2 a.m.

The HP OpenVMS engineering group made the decision to provide patches for some versions of OpenVMS, but not all of them. Thus, several different methods were necessary to cover every OpenVMS version.

The solutions listed below are for your benefit, PARSEC cannot guarantee its effectiveness because of the possibility of error in transmitting or implementing it.  It is meant to be used as a template for writing your own solution, and it may require modification for use on your system.

NOTES:

If the VMS version is not listed below and you have questions, then log a call with PARSEC at 866-3-PARSEC and we'll find a solution for you.

All of the TZ patches imply that a reboot is not necessary.  This is officially correct, but perhaps misleading.  If you are alpha 7.3 or higher, and you are using the AUTO_DLIGHT_SAV option, then there is a TQE in existence under the JOB_CONTROL process that is currently set to go off in April instead of in March or November instead of October.  Thus, you will either need to stop/restart the JOB_CONTROL process (something we don't really recommend on busy machines, but power users can decide if they can go that route), or reboot the machine.  Either of these steps will correct the TQEs that kick off.

All examples below are based on Eastern time.  You will need to modify rules according to your own timezone.  If you aren't sure what the rule should read, contact PARSEC at 866-3-PARSEC

==== VAX/Alpha 6.1, VAX/Alpha 7.1 (and variants), VAX/Alpha 7.2 (and variants) ====

<code>
1. *IF* DECnet Phase IV, no change in behavior, use UTC$CONFIGURE_TDF.COM

2. *IF* DECnet/OSI *AND* no DTSS, then wait until after the 2 a.m. time on the 
   appropriate date has been reached and then:

   a. Execute immediately, and place this command towards the end of your
      system startup file:

      $ DEFINE/SYSTEM/EXEC SYS$TIMEZONE_RULE "EST5EDT4,M3.2.0/02,M11.1.0/02"

   b. Then, each this time and all future time change dates, issue the following 
      commands:

      $ INSTALL := $INSTALL
      $ INSTALL SYS$COMMON:[SYSLIB]DTSS$RUNDOWN.EXE/shared/protect
      $ DTSS$SET_TIMEZONE := $SYS$SYSTEM:DTSS$SET_TIMEZONE.EXE
      $ DTSS$SET_TIMEZONE MODIFY

3. *IF* DECnet/OSI *AND* DTSS, 

   Get a copy of the DTSS$TIMEZONE_RULES.DAT included in the VAXTZ01_062 or 
   ALPTZ01_062 patch on the HPESC website.  Copy this file to your node, then 
   reconfigure the timezones via:
  
   $ @SYS$MANAGER:NET$CONFIGURE   and select option 5


      [5] Configure Timezone Differential Factor

   And follow the instructions. This will correct the four SYS$TIMEZONE* 
   logicals immediately and change the "next TDF" time within DTSS to reflect 
   the March 11th date for 2007.  You are now finished.
</code>

==== VAX/Alpha 6.2 (and variants), VAX 7.3 ====

<code>
1. *IF* DECnet Phase IV, no change in behavior, use UTC$CONFIGURE_TDF.COM

2. *IF* DECnet/OSI *AND* DTSS, install whichever patch is appropriate:
   VAXTZ01_062, ALPTZ01_062, VAXTZ02_073

   Reconfigure the timezones via:
  
   $ @SYS$MANAGER:NET$CONFIGURE   and select option 5


      [5] Configure Timezone Differential Factor

   And follow the instructions. This will correct the four SYS$TIMEZONE* 
   logicals immediately and change the "next TDF" time within DTSS to reflect 
   the March 11th date for 2007.  You are now finished.

3. *IF* DECnet/OSI *AND* no DTSS, then wait until after the 2 a.m. time has
   been reached and then:

   a. Execute immediately, and place this command towards the end of your
      system startup file:

      $ DEFINE/SYSTEM/EXEC SYS$TIMEZONE_RULE "EST5EDT4,M3.2.0/02,M11.1.0/02"

   b. Then, each future time change, issue the following commands:

      $ INSTALL := $INSTALL
      $ INSTALL SYS$COMMON:[SYSLIB]DTSS$RUNDOWN.EXE/shared/protect
      $ DTSS$SET_TIMEZONE := $SYS$SYSTEM:DTSS$SET_TIMEZONE.EXE
      $ DTSS$SET_TIMEZONE MODIFY
</code>

==== ALPHA 7.3 or 7.3-1 ====

<code>
This procedure is written for the customers in the Eastern timezone.  If your
system is in another timezone, you will have to modify it to the appropriate 
name.  For example, the US_EASTERN. filename may become the US_PACIFIC. filename.
The steps are identical though, just the filename changes.

PREP WORK:

You will need to find a machine that has already installed the TZ patch.  For
example, the VMS732_TZ-V0300 or VMS82_TZ-V0200.  If you do not have such a file,
you can pull down one of those patches and issue these commands:

  $ CREATE/DIRECTORY [.TIME]   ! good idea to have separate directory
  $ SET DEF [.TIME]            ! get into that new diretory
  $ COPY patch-name-source []  ! copies it here
  $ RUN patch-name.ZIPEXE      ! create .PCSI file
  $ PRODUCT EXTRACT FILE *     ! copies all files into this directory

Now you will need to find your US_EASTERN. or appropriate timezone file.


STEPS

1. Copy your US_EASTERN. file from the patch directory and place into the 
   SYS$COMMON:[000000.SYS$ZONEINFO.SYSTEM.US] directory.

   NOTE: SYS$COMMON:[000000.SYS$ZONEINFO.SYSTEM.CANADA] for Canadian customers.

2. *IF* running DTSS, then issue:

   $ @SYS$MANAGER:NET$CONFIGURE   and select option 5

      [5] Configure Timezone Differential Factor

   And follow the instructions. This will correct the four SYS$TIMEZONE* 
   logicals immediately and change the "next TDF" time within DTSS to reflect 
   the proper Sunday in the future.  You are now finished.

3.  *IF* running AUTO_DLIGHT_SAV = 1:

   $ @SYS$STARTUP:UTC$TIME_SETUP.COM  ! follow the menu appropriately.
   $ @SYS$SYSTEM:SHUTDOWN             ! reboot the machine

   This will correct the four SYS$TIMEZONE* logicals, correct the rule listed
   in the file TDF$UTC_STARTUP.COM, and create appropriate Timer Queue Entries
   (TQEs) under the JOB_CONTROL process for the next time change.

4. *IF* Neither DTSS nor AUTO_DLIGHT_SAV, thus "by hand"

   At 2 a.m on the appropriate Sunday, you will run the UTC$TIME_SETUP.COM, 
   which will correct the four SYS$TIMEZONE* logicals, and change the rule 
   listed in TDF$UTC_STARTUP.COM so that your logicals will be correct after 
   system boots.  No reboot is necessary at this time.
</code>

==== ALPHA 7.3-2, ALPHA/ITANIUM 8.2, ITANIUM 8.2-1 ====

<code>
1. Apply the appropriate patch of:  VMS732_TZ-V0300, VMS82A_TZ-V0200,
   VMS82I_TZ-V0200, VMS821I_TZ-V0200

2. *IF* running DTSS, then issue:

   $ @SYS$MANAGER:NET$CONFIGURE   and select option 5


      [5] Configure Timezone Differential Factor

   And follow the instructions. This will correct the four SYS$TIMEZONE* 
   logicals immediately and change the "next TDF" time within DTSS to reflect 
   the next appropriate time change date.  You are now finished.

3.  *IF* running AUTO_DLIGHT_SAV = 1:

   $ @SYS$STARTUP:UTC$TIME_SETUP.COM  ! follow the menu appropriately.
   $ @SYS$SYSTEM:SHUTDOWN             ! reboot the machine

   This will correct the four SYS$TIMEZONE* logicals, correct the rule listed
   in the file TDF$UTC_STARTUP.COM, and create appropriate Timer Queue Entries
   (TQEs) under the JOB_CONTROL process for the next time change.

4. *IF* Neither DTSS nor AUTO_DLIGHT_SAV, thus "by hand"

   After 2 a.m on the appropriate Sunday, you will run the UTC$TIME_SETUP.COM, 
   which will correct the four SYS$TIMEZONE* logicals, and change the rule 
   listed in TDF$UTC_STARTUP.COM so that your logicals will be correct after 
   system boots.  No reboot is necessary at this time.
</code>


==== ALPHA / I64 8.3 ====

<code>
For the US customers, the solution is already built into the OpenVMS codestream.
For Canadian customers, it depends on which Provence your machine is located.  
If you are in the Mountain or Pacific timezones, your timezones may not be correct.  
You can check by looking at your SYS$TIMEZONE_RULE logical.  If it shows:   

   "...M3.2.0/02,M11.1.0/02" 

then you are operational.  If it doesn't show that, then install the appropriate
patch of either VMS83A_TZ-V0100 or VMS83I_TZ-V0100
</code>

==== ALPHA / I64 8.4 and above ====

<code>
The solution is already build into the OpenVMS codestream.
</code>

The above information is specific to perhaps using the wrong timezone rules for your system.  If that doesn't seem to address the issue, then log a call with PARSEC at 866-3-PARSEC and we'll be happy to assist you.