As anyone any knowledge about a cluster combination as above and then say moving the V7.2-1 Node to V7.3-1 or V7.3-2? I know this is not a supported configuration but will it work?
I know this is not a supported configuration but will it work?
For VMS, generally spoken "unsupported" is NOT equal to "won't work". For instance, a cluster of Itanium and VAX is "unsupported", but I've seen this type of clusters - even a IA64-AXP-VAX one - at HP-events.
In case it doesn't work, you ARE in trouble since that's what "unsupported" means: "It will (eventually) work; if it does - fine. If is doesn't - you shouldn't have tried in the first place" (Just my interpretation)
So: Simply try it out. Chances are it'll just work.
BUT BEWARE: This may be true for VMS itself (and clustering in particular) but it does not mean that your business software will be happy with this configuration.
Willem Grooters OpenVMS Developer & System Manager
Alpha V6.2, V7.3, VAX V6.2 are the exact versions - no -1, etc. Volker gave the way of checking that the fundemental cluster comms will work. This does not mean everything will work. Hoever the cluster I have has been running for quite a while and seems to be fine.
Pick up the 6.2 patches, and read thu the release notes.
In the 6.2 time frame there were some patches that needed to be installed BEFORE a mixed version V6 + V7 were possible.
I would give you the specific patch names, but alas, my Prod Hist only reports the amalgamated UPDATE patch, which we apparently installed shortly before (ie, in preparation of) the VMS upgrade.
IIRC, there were some Shadowing issues, and some DECnet V issues (heh, it's been over 5 years, and this IS from human memory, so check it before you take my word for it!)
Success
Jan
Don't rust yours pelled jacker to fine doll missed aches.
Please remember that mixed version clusters are only ever "migration support". Which means you're only expected to run them for the duration of a rolling upgrade. HP accepts that it may take weeks or even months to complete the upgrade, but, the expectation is that once you've started to upgrade your cluster, you will eventually complete it.
The upshot is, if you report a problem in a mixed version cluster, which is found to be caused by the mismatch, the focus of engineering and services will be on making sure you can get the lagging nodes up to the revision level of the leading nodes.
It all comes down to qualification. The number of version combinations expands exponentially and we simply don't have the resources to qualify all possible cluster permutations. (of course, if you have a specific configuration you NEED to have qualified, please address your truckload of cash to 110 Spit Brook Rd Nashua, NH... :-)
In your case, I'd expect your existing cluster to continue to work, but I think V6.2 and V7.3 are getting too far apart to be worthwhile. The question arises, why would you want to upgrade to V7.3 when the presence of a V6.2 node will prevent you from using most of the new features? No ODS5, no dissimilar shadowing, no dynamic volume expansion, no minicopy, no minimerge, no posix compatibility, etc...
Please think about what you're really trying to achieve. I know it's very cool to have a large cluster with zillion's of versions (guilty m'lud! ;-), but in a real production environment there's no point in pushing the envelope for its own sake. It may make more sense to split the cluster in two and use alternate mechanisms to share data and resources.
