Upgrade VMS 7.3-2 to 8.3

[Robert_Boyd]

I want to second Jim Geier's suggestion about building a copy of the distribution on a hard drive.

For my upgrades to V7.2-2, V7.3-2 and V8.2 and V8.3 I built bootable hard drives with the distribution media. I also loaded up all of the relevant patches for the system, TCP/IP, DECnet, and other layered products as well.

This shortens the actual upgrade process dramatically in some cases. If you have an environment where you can have the volume in a movable drive or on a SAN where you can present it to different systems as needed that can be a real win.

[Rich Hearn]

Volker,

Thanks for your response. Your thought of a 3rd root for the Test System is intriguing, but that would require more time than I currently have to be able to "play" with Cluster_Config.Com a few times on the Test system before I feel comfortable with doing it on the "live" system disk.
I'm looking to do the upgrade a week from this Sunday - Dec 9th. I have no doubt that if you're familiar with doing it, it could be done in short order. I, however, haven't done it in 15 years - I wouldn't feel comfortable taking that kind of chance on the future system disk without some practice. Doing the re-compile requires another copy of the DB (200GB) so the new version of the app can be brought up. Not able to do that - even ignoring the support contract concerns - none purchased for the test system.


Bob,

A common system disk is not our configuration... the 2 cluster members are 6 miles (physically) apart, so we have separate shadowed system disks for that reason. Yes, we could've put the roots on the HSV disks, but felt that it would be easier to diagnose if the node could, at least, be booted. We'd then have that to work with even if we lost the network connection to the HSV disks.

Regarding re-compiling the routines; they get stored in one of the DB's for the Cache system - it's not like re-compiling a different version of C code that I can store on my VMS disk - these are stored in the MUMPS environment. You have given me pause to the idea of using my current shadow copies - I'm thinking of re-shadowing the systems disks on the day before the upgrade (Sat the 8th) and do the upgrade on those - changed common files will be minimal. Thanks for that thought in particular. Also thanks for your time and other thoughts - do 'preciate


Jim,

Thanks for your thoughts on this. Interesting that you were told the routines didn't have to be re-compiled. I was told we had to. Originally, I was told the downtime for the upgrade with the re-compile would take the weekend - obviously, that's not the case. I was remembering the 3 hour time needed last year when we went from v5.0.5 to v5.0.20 so I'm figuring on 6 hours total downtime. If it's less, *no one* evers complains - but 2 minutes after the expected downtime passes with no system, the phone starts ringing - go figure... :^)

Glad to hear that you did a very similar upgrade as I'll be doing & it went well. I understand the "gotcha" you're talking about - my initial attempt with the actual test system disk also reminded me of the need to clear the shadow flag. Ahh, it's nice to know I'm still human... We start our upgrade at 05:00 - I will *not* interrupt our backups (00:00 - 05:00 if a failure occurs). I can well understand the frustration of not being able to do rolling upgrades - but since we get downtime once a year, I don't mind the total shutdown. I don't have any logical disks on our systems, but it sounds like it merits looking into. I will do that - for the future. I don't want to try to "squeeze" too much "new" in for me to do for the next week and a half.


Robert,

I appreciate your thoughts as well. Looks like I'll have to set up a disk on the SAN than can be used as a logical disk(s) for all kinds of items (VMS, Multinet, Cache)

Thank you all for your thoughts.
Rich

[Dana Conroy]

I'm planning to upgrade our GE/IDX OpenVMS 7.3-2 cluster (running a non-clustered Cache 5.0.20 environment) to OpenVMS 8.3/Cache 5.0.21 in March 2008, so I've found this thread particularly helpful - thanks to all!

We are not yet taking advantage of Cache's clustering capabilities, but I am grateful that I'll be able to do a rolling upgrade.

Rich - An upgrade from Cache 5.0.5 to Cache 5.0.20 required compilation of all GE-authored Cache classes due to a significant change in Cache's class library that occurred around version 5.0.12. I'm not expecting another round of compiles for this upgrade.

Jim - Glad to hear (but not surprised) that your upgrade went well! No routine or class compiles were needed for your Cache 5.0.20 to 5.0.21 upgrade?

Dana

[Rich Hearn]

Dana,

Thanks for the "memory jog"; I had forgotten about the ZLIB/ZCALL upgrade. I'll give GE/IDX another "ask" regarding the re-compile. It would be nice if it's not required.

Tnx agn
Rich

[The Brit]

Rich,
One other thing that you need to keep in mind, (while you ponder your options), is that you cannot upgrade a shadowed system disk! i.e. the system must be booted with SHADOW_SYS_DISK = 0. See section 4.8 of the upgrade manual.

This may impact some of the suggestions above.

Dave.

[Rich Hearn]

Dave,

Thanks for the thought. I was reminded of that fact when I tried to do one of my test cluster nodes system disk - the upgrade process promptly informed me that you can't upgrade a shadowed system disk. Gotta love it when the system "reminds" you... oops :^)

Thanks,
Rich

[Jim Geier_1]

Dana and Rich,
With our Cache' upgrade from 5.0.20 to 5.0.21, we were at IDXtend 9.0 with no GUI, so no routine or object compiles were needed. My understanding is that had we been at Flowcast 3.0 or 4.0 or using the GUI in 9.0, we would have had recompile objects, but not a full recompile of all routines.

Rich, I checked this with GE/IDX yesterday, so make sure you really have to recompile all routines and not just objects (I'm told there is a rather substantial difference in time required with routine compiles taking much more time).

We are now at 4.0, and starting the project to deploy the GUI, so my future Cache' upgrades will change.

[Jim Geier_1]

Rich and Dana,
ZLIB/ZCALL -- my notes from GE for the upgrade say that as long as you are running the minimum version documented as compatible, the ZLIB does not need to be reinstalled. I was also told that the ZCALL does not need to be rebuilt - and that surprised me. We were running ZLIB 9.4 and ZCALL 4.7. I decided to recompile and relink the ZCALL image because of the change in operating system version, and found that the CZF.EXE was exactly the same size. Then I just copied the CZF.EXE from one bin directory to another. We have 11 environments on our two-node non-production cluster, so I performed the Cache' upgrade 22 times on the non-production cluster. I found later that I had missed copying the correct CZF.EXE file to a couple of the bin directories, and neither Cache' nor the applications seemed to care. But I would recommend rebuilding the CZF.EXE image anyway.

(We did have to make a change to the ZCALL for the application version 9.0 to 4.0 upgrade, but that was months after the Cache' upgrade, and a completely separate issue.)

[Rich Hearn]

Jim,

Wow! You've been busy! Let me start with Thank You for all this information. I've got a question out to our IDX folks to see if the re-compiles are actually required.

We're not running the GUI at this point in time either, tho' we are on Flowcast 3.0 (it was optional for this version - tho' I'm told we *have* to get to v4.0 soon). Here's our version.txt info displayed by sylogin
VMS 7.3-2
MULTINET 5.1
CACHE v5.0.20
FLOWCAST 3.0
ZLIB 9.4
ZCALL 4.7
I appreciate you passing along the information about CZF.EXE - that's good to know. Ok, I've gotten the answer that they'll be doing the object re-compiles after the upgrade.

Thanks for all your efforts,
Rich

[Rich Hearn]

Just wanted to say "Thank You" to all of you who contributed to this thread. My upgrade went well (Sun 9-Dec-2007 from the VMS perspective) and I wanted to let you all know I'm gratefull for all your help.

Tnx agn,
RIch