Operating System - OpenVMS
1748058 Members
5041 Online
108758 Solutions
New Discussion юеВ

Re: Mixed version cluster + TCP/IP

 
SOLVED
Go to solution
Aaron Sakovich
Super Advisor

Mixed version cluster + TCP/IP

Hi,

I've got a development cluster that I've got to maintain 2 versions of VMS on -- current development environment and prior version for customer support (patch development, etc.)

We're currently running 7.1-2 cluster-wide. I need to upgrade 2out of the 3 nodes to 7.3-2. Yes, I know it's not supported, but that's the risk I'm going to have to take. I'm trying to educate myself now on potential problem areas and ways to avoid them (e.g., several new features introduced in 7.2/7.3 like cluster-wide logicals or APIs will be off-limits to developers.)

What I'd like to know is what I can get away with in terms of TCP/IP Services running on the multiple nodes in the cluster. I'm anxious to run 5.4 on the 7.3-2 nodes, due to our need to run SSH.

What's the highest version can I run on my 7.1-2 systems? (I'm thinking it might be 5.1.) Are there any potential known conflicts between the different versions of TCP/IP which would show up in a cluster (e.g., proxy db's)?

I know I'm treading on unfamiliar territory, but we've got to run these 2 versions for as much as a year. Ouch.

TIA,
Aaron
18 REPLIES 18
David B Sneddon
Honored Contributor

Re: Mixed version cluster + TCP/IP

Aaron,

Mixed version would imply multiple system disks.
In this case I wouldn't attempt to share any
"system" files between the two unless you know
they are compatible.
I would not share any files between different
versions of TCPIP.
The biggest problem you are likely to have is to
make sure the 7.1-2 system is fully up-to-date
as far as ECOs to increase the chances of the
clustering working.

Regards
Dave
John Gillings
Honored Contributor

Re: Mixed version cluster + TCP/IP

Aaron,

Technically speaking, TCPIP does not support sharing TCPIP files across a multi system disk cluster. So, if you have more than one system disk (which you must if you're running more than one version of OpenVMS), then you should have multiple TCPIP environments.

Highest version you can run on V7.1-2 is whatever you want! Since that version of OpenVMS isn't supported, it either works or it doesn't ;-)

In practice I'd expect it to "just work" even if you did share files. Indeed, now that the file formats have been standardised, I'd almost expect to be able to share them with Unix! On the other hand, I agree with David, I wouldn't try to share them across that version distance.

What I'm curious about is why you think you need to keep V7.1-2 around. Upwards compatibility is the rule in OpenVMS, so it's not credible that you have something that works on V7.1 but doesn't work on higher (supported!) versions. That's particularly true between V7.1 and V7.2, there wasn't a whole lot of difference between them.
A crucible of informative mistakes
Wim Van den Wyngaert
Honored Contributor

Re: Mixed version cluster + TCP/IP

You can also use 2 system disks fo the 3rd system. 1 for booting in 7.1-2 and 1 for 7.3-2. This way you can choose and even make it tripple boot, when that is needed.

Wim
Wim
Jan van den Ende
Honored Contributor

Re: Mixed version cluster + TCP/IP

John,

If I have read Aaron well, it is NOT to do with UPward, but with DOWNward compatibility!

If he has to support 7.1 systems, he'd better not link against higher versions.
And the other way-- he needs 7.3-2 for some functionalities NOT in 7.2, obviously for other customers.
You can hardly expect a supplier to be able to force ALL customers to upgrade synchronously, especially since THEY may also have other dependencies!

hth,

Proost.

Have one on me.

Jan
Don't rust yours pelled jacker to fine doll missed aches.
John Gillings
Honored Contributor

Re: Mixed version cluster + TCP/IP

Jan,

>If he has to support 7.1 systems, he'd better not link against higher versions.

Hang on a sec! The most common excuse we hear for not upgrading FROM V7.1 is that ISVs won't support or qualify on later versions. So you're saying that ISVs are claiming that customers are demanding they stay on old versions? Huh? You can't have it both ways!

V7.1 was released in 1996. V7.1-2 was 1998, about the same time as V7.2. V7.3 was early 2000.

I don't have a problem with people taking their time to upgrade, but 8 YEARS?

If you must run an old version in a stable environment, that's fine, but when we get questions like this one "we know this is unsupported, but what problems can we expect?" Guess what folks... that's "support".

I wouldn't recommend running this mix of versions in a cluster for any longer than a rolling upgrade. If it's vital that you retain a V7.1 system, then split it out of the cluster and run it as an independent node, or just leave yourself the capability of booting a node as a V7.1 system when required.
A crucible of informative mistakes
Jan van den Ende
Honored Contributor

Re: Mixed version cluster + TCP/IP

John,

please do not get _ME_ wrong!
I am all with you, and I strongly endorse your arguments.
But there ARE sites around that run multiple apps, and if one of them does not qualify on a higher version, that might be a reason to ask your ISV to keep supporting an older version of VMS.
.. and I _DO_ have some experience with software that did NOT rum on 7.3, while it DID on 7.2. Luckily our relation with the ISV was such that they were prepared to bring their objects and have us re-link them. That solved it for us, but not everybody is always granted such luck!

So, to me, the original question remains a valid one.
And though I feel like your "keep a reboot available for high need", this is dependant on the frequency of the need for the older system.

Remember a complicating factor in this can be the withdrawal from VMS of the PROGRESSes and SYBASEs of this world. Sometimes BIG legacy systems depend on them.
And you do lightly not do away with legacy systems, because they ARE the "stuff that works"!

Maybe HP should do more to encourage ISV's to stay on (come back to/come to?) VMS.

Proost.

Have one on me.

Jan
Don't rust yours pelled jacker to fine doll missed aches.
Aaron Sakovich
Super Advisor

Re: Mixed version cluster + TCP/IP

Sorry for not replying earlier -- I was having problems getting logged into the forums.

Let me respond to each of your responses. But first, let me start off by hopefully answering a common question: why?

We write financial software for banks, dealing with billions of dollars. We NEED a stable environment, and have been burnt in the past when runtime libraries, compilers, or layered products have changed. Yes, these items are supposed to be backwards compatible, but I can give you explicit examples of times when upgrading to the newest COBOL runtime broke stuff. With quality control and application testing, we can't afford to recertify all of our apps just to be able to provide patch support in a new development environment because we have to upgrade the OS on one node in our cluster.

And why not break one node out of the cluster? We work out of a common source environment with several hundred gigabytes of programs and data. We're not interested in breaking that environment up into duplicates just to be able to support the possible creation of a few patches in the next few months.

Now, if the second guessing is over, let's move on to the technical topic.

David: yes, we've individual system disks for each node, but we do share items, too -- e.g., SysUAF and proxy db's. One of my specific concern is for our UCX$Proxy.dat file -- tips or suggestions on how to ensure a clean migration to v5.x, plus an answer to the question 'can I share a v5.1 proxy data file with v5.4?' would be helpful.

John: very funny! But can you think of specifics that will break if I try to run 5.4 on 7.1-2??? How about 5.3?

Jan: yes, thank you very much. While we've forced our customers to upgrade their OS, we're still in the process of getting all the apps and runtimes up to a 7.3-x compatible version.

John again: yes, 6 years is a long time. A few billion dollars is a lot of money. I'm not asking for "support" from HP, hence my coming to this forum rather than logging a call through normal channels. If anyone has any experience or knowledge they care to share with me so that I can move our development environment and customers to 7.3-2 while still supporting our old 7.1-2 system for patching, more points for them.

Jan again: thanks again for your sympathetic customer oriented attitude.

I still need to know what's the highest version of TCP/IP that was ever certified to run on OpenVMS v7.1-2. (Back in the old days when SPDs were stored in .TXT and prior versions were kept online, I could have answered that myself. Permit me to curse .PDF SPDs here and now. Blecch.)

Regards to all,
Aaron
Willem Grooters
Honored Contributor

Re: Mixed version cluster + TCP/IP

John,
I MUST disagree in some extent with you.

It is the CUSTOMER who decides the level of OS, not the ISV, or even HP; there can be VERY GOOD business reasons NOT to upgrade.

The problem our customer faced was uncertainty, so they didn't upgrade. As a development team we just had to stay behind (just because of just "upward compatibility" - since all we developed on our old systems would run on higher versions - both VMS (6.2) and development/runtime (Synergy - AKA DiBoL, 5.7.6).
Now all production systems will have to upgrade to 7.3-2 (since that will be supported 'indefinitively') we too could go ahaead - 7.3-1 for first development, on new hardware, in the beginning of 2004. When ALL customers have upgraded, we'll go to 7.3-2 as well (beginning 2005). However, we'll stay on our old DiBoL version for the simple reason that higher versions would mean BIG changes in the software.

Although our 'requirement' is now VMS 7.3-1 at least, it's not very strict. It dosn't have to be: built under 7.3-1, our main (DiBoL) software did run flawlessly under VMS 6.2 - just ONE (lib$) routine had to be replaced by it's system (ss$) variant.
Some middleware is written in C, and when linked locally, it will run on 7.x versions. On 6.2, it needs to be relinked differently but even then it will just run. But we won't support that.

So yes, there IS be a good reason for another, older system.
I would suggest to keep this one machine on 7.1-2 with TCPIP 5.1 - but with all relevant latest ECO's, this system NEEDS to have it's own system disk, just to isolate all protential problems. All autorization files (SYSUAF.DAT, RIGHTLIST.DAT et all) can be placed on a separate disk, accessable by all nodes in the cluster, which makes maintenance relatively simple. Your development area can be on a shared disk, you can do development of your application on 7.3-2 (and 8.x, in time) and built (and test!!) it on 7.1-2 when required. In that case, you'll have one codebase.

Willem
Willem Grooters
OpenVMS Developer & System Manager
Jan van den Ende
Honored Contributor

Re: Mixed version cluster + TCP/IP

Yes, I am with Willem a long way.


Your development area can be on a shared disk, you can do development of your application on 7.3-2 (and 8.x, in time) and built (and test!!) it on 7.1-2 when required. In that case, you'll have one codebase.


And yes, this works fine.
But, maybe superfluous, but I want it explicit:
This _REQUIRES_ your build procedures to use different directory structures for SOURCE and OBJECT environments. It is relatively simple to set up, but MAKE SURE no-one srews up!!

Proost.

Have one on me.

Jan
Don't rust yours pelled jacker to fine doll missed aches.