DST Patch for VMS Ver. 7.1-2

[A. D. Calaiezzi]

We are useing VMS Version
Welcome to OpenVMS (TM) Alpha Operating System, Version V7.1-2 on node PRMOPS

The HP website says the following:

ACRTL

If you use ACRTL on OpenVMS version 7.3-2, you must apply the ACRTL patch kit VMS732_ACRTL-V0300 to your version 7.3-2 system (in addition to applying the OpenVMS timezone patch kit VMS732_TZ-V0300). For other versions of OpenVMS, please note the following:

Timezone patches for OpenVMS versions prior to version 7.3-2 do not require any corresponding ACRTL changes.

DOES THIS MEAN WE DO NOT HAVE TO PATCH OUR SYSTEM?

Tony

[Andy Bustamante]

It all depends.

The system prompt can be changed independently of the operating system version. Try:

$ show system/noprocess

to verify your version of VMS. VMS 7.2-1 is out of support, please see http://www.openvms.org/stories.php?story=07/02/08/6646402 for information about patching older version of VMS. The absence of information about 7.2-1 doesn't mean there are no requirements, it means it's no longer supported.

Depending on your application environment you may just be able to ignore or manually update the system time and time zone offset. If you're running a third party application, you should also check with that vendor, Oracle for example.

Andy

[Hoff]

Nope. The cited text just means that the earlier releases didn't have the particular C function that required the changes to the C RTL. It doesn't mean that earlier releases don't have timezone rules. They do. V7.* and later have these, as do earlier systems using DECnet-Plus and DECdtss (DTSS) timekeeping.

From Charlie McCutcheon (one of the C gods): "The ACRTL kit was to support the timezone changes with the functions in the CRTL that allow you to manipulate timezones. It should work fine without the Timezone kit"

I was mildly surprised that HP indicated that ACRTL was optional for V7.3-2, as figuring out what actually uses that function in the C RTL is not trivial. Applications and LPs use C and the C RTL from all over the place, and barring a review of everything that might call into the function(s) involved... It would have seemed safer and simpler to mandate the ECO.

As for your question about V7.1-2, please consider a look at these two recent threads here in ITRC:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1105811
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1105389

and call us back. Hopefully those will answer your questions, or at least get you pointers to more resources.

Probably the worst that would happen in most cases at most installations is that SMTP MAIL and a few other operations will be off by an hour. This probably won't be a crisis come Monday. Though I can't say that this DST change won't be a crisis for any particular site. It might be. If you can manage to fit this in before Sunday morning, I'd certainly encourage a test pass or two.

Stephen Hoffman
HoffmanLabs

[A. D. Calaiezzi]

I FTP the TIMEZONE.A-DCX_AXPEXE file to my ALPHA. It created a file called TIMEZONE.A. How do I extract the appropriate timezone? I tried the following command and got the following response: run SYS$SYSROOT:[SYSMGR]TIMEZONE.A
%DCL-W-ACTIMAGE, error activating image SYS$SYSROOT:[SYSMGR]TIMEZONE.A
-CLI-E-IMGNAME, image file PRMOPS$DRA0:[SYS0.][SYSMGR]TIMEZONE.A;1
-IMGACT-F-NOTNATIVE, image is not an OpenVMS Alpha image
PRMOPS_MOPSSYS> type TIMEZONE.A;1
%TYPE-F-WRITEERR, error writing SYS$OUTPUT:.;
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-EXQUOTA, process quota exceeded

[Hoff]

The file you are looking at is a BACKUP saveset, though the directions don't seem to indicate that. (And rather oddly, it doesn't have the usual .BCK or other such file extension for a BACKUP saveset, either.)

$ CREATE/DIRECTORY [.SCRATCH]
$ SET DEFAULT [.SCRATCH]
$ BACKUP TIMEZONE.A/SAVE [...]

To list the contents of the saveset:

$ BACKUP TIMEZONE.A/SAVE/LIST

There are also some details on maintaining the timezone definition files in the OpenVMS FAQ, as well.

[John Travell]

TIMEZONE.A ? Is this a VMSINSTAL kit ? If so,
$ backup/list TIMEZONE.A /sav
should show you a file called KITINSTAL.COM, probably as the first file listed.
If it does, the installation procedure for this kit is:
$ @sys$update:vmsinstal
and answer questions...
JT:

[A. D. Calaiezzi]

I have extracted the files, the next step says, "Copy the replacement file into the timezone info directory replacing the existing file. Then

$@SYS$MANAGER:UTC$TIME_SETUP"

Is the timezone info directory sys$manager:?
Is there any way to check the current contents of the UTC$time_setup, befor I start?

What should I check after the reboot?

Can I still use @sys$examples:daylight_savings.com
to schedule the time change?

How can I check to see if it will work without changing the time?

[Hoff]

>>> $ backup/list TIMEZONE.A /sav
should show you a file called KITINSTAL.COM, probably as the first file listed.
<<<

I'd thought of that too, but the VMSINSTAL kits are usually nameNNN.A, where the NNN is a numeric field; a VMSINSTAL kit version number string.

>>>
I have extracted the files, the next step says, "Copy the replacement file into the timezone info directory replacing the existing file. Then

$@SYS$MANAGER:UTC$TIME_SETUP"
<<<

I'd tend to have the next step being "make a BACKUP or two and particularly a BACKUP -- or RMU/BACKUP or other such -- of critical application data that might have business-critical standing, lest something go badly wrong either during the timezone changes or during subsequent testing."

But then, I'm also somewhat paranoid.

>>>
Is the timezone info directory sys$manager:?
<<<

No. It's another directory hanging off of the SYS$SYSROOT system root directory.

Look around underneath the directory SYS$COMMON:[SYS$ZONEINFO...]

>>>
Is there any way to check the current contents of the UTC$time_setup, befor I start?
<<<

The timezone files are text files. You can read them. Some of which are actually even interesting reading.

>>>
What should I check after the reboot?
<<<

That's up to you. I'd tend to shut down, boot convesationally with the SETTIME parameter enabled to prompt for the system time during boot, and would test the roll-over from early Sunday morning at a minimum. But as that's a few days away, I might well be tempted to just perform the BACKUP, REBOOT, and check the active timezone rule to see when it lists the scheduled change-over. I don't know off-hand if the logical name containing the rule itself will be manifested, or if you'll have to dig around for that detail. (That seems to vary by configuration and LP and other factors.)

Stephen Hoffman
HoffmanLabs

[A. D. Calaiezzi]

I did a search for Zone
and found the following:

Directory DRA0:[VMS$COMMON]

SYS$ZONEINFO.DIR;1

Total of 1 file.

Directory DRA0:[VMS$COMMON.SYSEXE]

SYS$TIMEZONE.DAT;4 SYS$TIMEZONE_SRC.DAT;4

Which dir do I move my patch to?

[Hoff]

Some more formal help with this system would potentially be beneficial, with tasks including reviewing BACKUP status and operations, tuning, fragmentation and other related matters, with some assistance on operations and commands and such, as well as moving forward to a supported OpenVMS release.

I'd tend to suggest the DIRECTORY command, rather than the SEARCH command. The timezone files go in a subdirectory of the timezone file I specified.




$ dir sys$common:[sys$zoneinfo...]

Directory SYS$COMMON:[SYS$ZONEINFO]

SYSTEM.DIR;1 USER.DIR;1

Total of 2 files.

Directory SYS$COMMON:[SYS$ZONEINFO.SYSTEM]

AFRICA.DIR;1 AMERICA.DIR;1 ANTARCTICA.DIR;1 ASIA.DIR;1
ATLANTIC.DIR;1 AUSTRALIA.DIR;1 BRAZIL.DIR;1 CANADA.DIR;1
CET.;1 ....



$ dir sys$common:[sys$zoneinfo...]*north*

Directory SYS$COMMON:[SYS$ZONEINFO.SYSTEM.AUSTRALIA]

NORTH.;1

Total of 1 file.

Directory SYS$COMMON:[SYS$ZONEINFO.SYSTEM.SOURCES]

NORTHAMERICA.;1

Total of 1 file.

Grand total of 2 directories, 2 files.

$ type SYS$COMMON:[SYS$ZONEINFO.SYSTEM.SOURCES]NORTHAMERICA./page

# @(#)northamerica 7.2

###############################################################################

# United States

# From Arthur David Olson: