QM upgrade – too easy

Some of you will recall a recent blog entry where I documented some of my experience upgrading Unidata and Universe. I just finished upgrading QM. Dang, I love it when it’s easy.

I confess I panic whenever I need to upgrade anything. Familiarity does indeed breed contempt. I’m very familiar with all of the issues that can go wrong in an upgrade, and therefore very contemptuous of any process that intends to lay waste to my environment in the name of progress. They don’t call it DLL HELL for nothing. You upgrade "this" and it blows up "that". And before Linux people laugh too hard I’ll remind you that package dependencies present the exact same issues and I’ve had to completely re-install Linux systems just to get them back to a functional, pre-"up"grade state.

The trick to all of this upgrade stuff is to do it a couple times in a test environment before you do it in a live environment. Get familiar with whatever might go wrong, figure out how to fix it, and then do the real upgrade. Some sites don’t have this luxury. Since I’m using vmWare for all of my MV DBMS environments, I can turn off disk updates, and see what happens without fear of the updates trashing my data. When I’m comfortable with the process I’ll get backups, then turn on disk updating, then do the exact same process all over again.

MV upgrade notes, and the README docs for a lot of products, usually don’t include this key bit of critical information : Do we Install on top of an existing environment to upgrade, or do we need to Uninstall first, then re-install like it’s a new environment. I always read the README before I do an install or upgrade but I’m usually still left wondering. So I usually ask DBMS product support people about this before I do the deed. Sure, I have notes about upgrades to remind me how I did it last time, but if the process changes from version X to Y and this isn’t in the version Y doc, can we really rely on the notes from version X?

For products that say "install on top of the current environment" we still see in some cases that the new install creates a new entry in Add/Remove programs because the developers changed the product description. Since it’s too tough for developers to tell you how to remove the Add/Remove entries for version X, you wind up with both version X and Y in your Add/Remove programs screen. Isn’t that special?…

With QM, the process is to install on top of the existing environment – no need to go to Add/Remove programs and uninstall. The QMSYS account/directory is updated with all of the new binary information for the system, and the UPDATE.ACCOUNT verb just needs to be run to update the verbs in all of the account VOC files.

The QM upgrade (to 2.8-4) was simple and flawless. I was very pleased. Honestly – the actual activity took only about a minute. All of my testing, backups, and worrying took the other 2 hours of my effort. I think it’s safe to say that the only thing I really needed to do was to get my entire QM database folder tree off of the system (5 minutes?) then do the upgrade, and it would have been completely finished.

I’m not sorry I did the testing up-front and I don’t recommend that anyone assume that my experience portends their own. Get your backups and do your testing. Try to make sure you can fall back to a prior functional release just in case you find something isn’t working as expected after you’ve gone live. But if you’re running QM (or planning on it) it’s reasonable to assume that the process should go quickly and without a hitch.