Time Zone Patch

[Fred Sprenger_1]

I have an OpenVMS7.2 VAX Cluster of 4 VAX7700's identically configured using NTP for time sychronization. Will the patch I found for OpenVMS for VAX 7.3 (VAXTZ02_073) work and or cause any known issues?

Thanx for answering my question.

Fred

[Hoff]

I doubt anybody over at HP has particularly tested this combination with any seriousness.

What is your relative tolerance for risk, and for local testing and related support?

You might need to rejigger the VMSINSTAL kit as a start, as it would not surprise me that it won't install without a tweak or two. That rejiggering should be pretty simple, just use BACKUP to pull the kit apart, adjust KITINSTAL, re-roll the kit, and try it.

Then test the results, after the installation.

The most reliable would be an upgrade to the current OpenVMS VAX release; to V7.3. You'll get the other patches with that upgrade, too.

As for previous discussions, you might want to start here:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1102917

Though unlike that thread, you won't have to deal with Java, as you're on OpenVMS VAX, and Java isn't.

It might well work. Try it. Tweak the kit. Test it. Let us know.

Stephen Hoffman
HoffmanLabs

[Fred Sprenger_1]

Unfortunately since this is a mission critical business system with a very flackey application and no test environment upgrading to 7.3 is definitely a no go.

I am just hoping that there is someone out there that has applied this patch to an VAX 7.2 environment with a degreee of sucess.

Regardless thanx for your input.

Fred

[Jan van den Ende]

Fred,

to start with,

Welcome to the VMS Forum.

Secondly, for the way to say Thanks< see

http://forums1.itrc.hp.com/service/forums/helptips.do?#33

Thirdly,
If this system really is that critical, then you REALLY should convince Management of the equally critical need for a "sandbox" (which can also serve as a spare in case of need).
In that sandbox you can try 7.3 without risk, and it would not surprise me if you find that even your "very flackey application" would gain in stability and performanc.

Proost.

Have one on me.

jpe

[Hoff]

Your configuration is stable on V7.2 and you're not spending time and effort on the configuration. It works. It's reliable. There is eventually and seemingly inevitably a cost to that same stability, unfortunately.

Should you need support for a critical problem with OpenVMS itself here, then you'll likely be encouraged to roll forward to V7.3. Regardless, that V7.3 upgrade should not be a significant change to your configuration. I'd be surprised if that upgrade perturbed anything, too.

Assuming source code and with prerequisite products available, I'd also be looking at what to do with the configuration in general. A couple of Integrity rx2660 servers will use far less space, far less power, and far less hardware support than a flock of VAX 7000 model 700 series boxes with the usual accouterments. And each of these 2U boxes will be seriously faster than your entire configuration, and with massively more storage.

The other approach forward (for space and for various other savings) would be emulation, as most any current VAX emulator would be seriously faster than these VAX 7000 series boxes. This requires fewer changes to the existing applications, assuming you have no hardware-level dependencies. (Weird XMI widgets, for instance.)

The least-change approach is to determine if the timezones matter for your specific configuration. There are certainly established configurations that are switched over manually twice a year, and that do not utilize nor particularly need the daylight saving time (DST) or even the timezone settings. This was the classic environment on OpenVMS for eons. C and some more recent applications can and do play into this TZ and DST requirement here, however.

Rolling your own fix is certainly potentially viable. Probably even fairly straightforward, if all that's required here is resetting an installation-time version check. (I have not looked at the TZ kit.) Though even assuming somebody else has built and tested that approach and confirms it here, it's not clear that what testing was performed would match your environment.

Here, I'd tend to assume it would be safest and most expedient to roll forward to V7.3, to ECO it, and to apply the other mandatory ECO kits for that release. The other benefit: with the approach of an upgrade, you have somebody to call if something should go off the rails here. And you would again have access to the current ECOs for OpenVMS.

Unfortunately, there's no good and no easy and no certain answer here. And not that a production site such as your own would likely want to commit to without making a rather more detailed look at the associated options and risks of each. And testing.

Stephen Hoffman
HoffmanLabs

[John Gillings]

Fred,

>I am just hoping that there is someone out
>there that has applied this patch to an
>VAX 7.2 environment with a degreee of
>sucess.

Easy (dumb) answer. A V7.3 patch will not install on a V7.2 system. It will fail the version check.

In the case of the time zone patch, it's really just a bunch of TEXT changes to your timezone definition files. You can do these manually yourself. Break open the V7.3 patch kit (it's a BACKUP saveset), and dig through the KITINSTAL procedure to work out what it's doing.

Your most likely task is to compare the TZ definition files provided in the kit with those on your system. Merge in any changes (or just replace the files) and recompile them (sorry, I don't have a VAX available at the moment to look into the kit file and see how it works)

HP doesn't support V7.2, so you're on your own, unless you want to engage (ie: pay for) the services of an independent consultant.