Patching 7.3-1 for the 2007 DST transition rule change

[Travis Craig]

I've forgotten how to get around this problem (if I ever knew). When I run the zic command that was shown in http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=990561, I get the following error:

Can't create directory sys$common:[sys$zoneinfo.system]/US: non-translatable vms error code: 0x186D4

(The error code is a file specification syntax error; no surprise there.)

I think there is a way to turn on understanding of UNIX file specification format, but I can't remember what it is.

I am running OpenVMS V7.3-1 on an Alpha and am trying this experiment because I have customers on 7.3-1 and H-P has no plan to provide a patch to 7.3-1 for the 2007 daylight saving time transition rule change in North America. If someone has a better idea than editing the source file and running zic, I am listening (with my eyes).

--Travis Craig

[Volker Halle · Accepted solution]

Travis,

try $ DEFINE DECC$FILENAME_UNIX_ONLY TRUE (don't know if the CRTL supports this logical on V7.3-1).

You may also try to manually edit SYS$STARTUP:TDF$UTC_STARTUP.COM and modify the last line - over here it's:

$ DTSS$SET_TIMEZONE INITIALIZE "MET-1MEST-2,M3.4.0/02,M10.5.0/03"

Wouldn't it be also possible to take apart the VMS732_TZ-V0200 kit and extract the required files ?

Volker.

[Travis Craig]

Thanks, Volker. It appears that the DECC$FILENAME_UNIX_ONLY logical has some effect on 7.3-1, because defining it gave me a different error message, which led me to the embarrassing discovery that my whole problem was a typo. Once I fixed the typo, my zic command worked fine, with or without the logical defined.

Then I ran my test program that exercises the C run-time library time routines and found the new rule is in effect for years 2007 and higher in the U.S. Pacific zone now, which was my goal.

You make an interesting point about the TDF$UTC_STARTUP.COM file. I see it has its own copy of the rule, but I wonder whether we need to change it, if we use NTP.

I had wondered about grabbing files from the 7.3-2 patches (TZ and ACRTL) too, but I don't know the answer to that one because I still don't know all the areas of the system that might be affected. Does anybody know for sure?

--Travis

[Volker Halle]

Travis,

assuming you use NTP for time synchronization. Note that NTP does NOT change the timezone rules and switch between standard and daylight savings time. NTP internally only works with GMT time.

The local system has to handle the timezone business to present a 'correct' local time.

Volker.

[Travis Craig]

Yes, is the file you mentioned part of the changing of the VMS system clock at daylight saving time transitions? I understand the VMS clock is still maintained in local time and is changed at the appropriate time as long as SYSGEN parameter AUTO_DLIGHT_SAV is set to 1.

--Travis

[Volker Halle]

Travis,

TDF$UTC_STARTUP.COM is called during boot (from VMS$BASEENVIRON-050_VMS.COM) to define the timezone rule.

Interestingly, I just found out, that the TDF$SET_TIMEZONE.EXE utility, which is called in the last line of TDF$UTC_STARTUP.COM, has built-in help, just RUN it and it will explain it's functions.

Note that running @SYS$STARTUP:UTC$TIME_SETUP always creates a NEW version of TDF$UTC_STARTUP.COM (or DTSS$UTC_STARTUP.COM if you're using DTSS). So if you manually edit that file, the changes may get lost, if someone manually executes UTC$TIME_SETUP.

JOB_CONTROL runs SYS$MANAGER:JBC$DST_COMMAND.COM to perform the time DST change, but that seems to try to read the timezone file (pointed by SYS$LOCALTIME)and create a new SYS$TIME_ZONE_RULE logical - so if you have not managed to patch the local timezone file, this may cause problems. It won't do this, if the timezone file does NOT exist - so this may be a workaround.

Volker.