Hi Dermot (surely) / also, there is a bit of additional information I noticed later in his reply at the very last regarding setting time expectations that I've now added in. Best (Mark)
The "side-by-side" upgrade is more when someone is migrating to a new system (hardware). That would move the Manager(s) from the old system to the new. Yea, it can be used to "migrate" from one partion to another (on the same hardware) but that is usually more work for no advantage.
I don't see how the "side-by-side" would be any quicker for "testing". To test MQ, one really has to test their application programs also. That means moving them over to the new system also. And every MQ application is also a "database application" or something similar. So that means moving the database over to the new system also. At that point, you might as well move everything from one system to another.....so if you have to fall back, are you saving everything on the new system and restoring on the old? I do not see how that is "faster fallback" I would expect the full system save/restore to take hours (each way...and that is not counting the other validations that someone would do) And if not a full save/restore, then it takes a long time to build a checklist of steps to migrate the selective products, files, users etc, and there is lots to go wrong.
Instead, the simple "upgrade in place" is simple.
An overview of the steps...
0) optional cleanup of old FDCs/Trace files etc
1) process all your messages
2) quiesce the Manager
3) save the MQ product (at v7 or whatever the current version is)
4) save the Manager data (library and directory)
5) install MQ v8 or 9
6) STRMQM which will migrate the Manager's data from v7 to the current version.
7) Test! If any issues are met with, business decision is made to revert to the older release
8) dltmqm
9) dltlicpgm to remove MQ v8/9
10) install MQ v7 (from save file in step 3)
11) CRTMQM
12) restore the v7 library and directory from save files of step 4
13) STRMQM and test.
(to complicate things, there are a couple of variations on the restore, such as just clearing the Manager's library and directory at the newer version...but we end up in the same place in most cases. We do have to worry a bit about the new objects created in the new version. And v7 uses the old directory structure vs v8+ using a new directory structure....but that is more tangential to the question for now.
Yes, there are some things that could make this more complicated...HA products like Mimix, etc. But even MQ Clustering isn't much of a concern.
I suppose the "side-by-side" may not need the full migration back to the first system....if the first system is still around. But fallback would mean changing all your networking stuff (as mentioned, CONNAME etc, unless the ip address switched in the side by side also) And any data processed would have to be addressed at some point also, or the databases would be 'out of sync')
The 13 steps overviewed above are much more straight forward and of less risk
SME does not prefer the "alternative" upgrade. (Use ms03 or dmpmqmcfg to capture the current config, delete the Manager entirely, upgrade mq product, crtmqm, replay the mqsc script) There are very good reasons to NOT do this. There are valid reasons you may want to do it.
Issues seen by the SME with the "alternative"
- using MS03, unsupported support pack, is unsupported.
- clustering. Even though the Manager has the same name, the unique name is different and that is critical for clustering. "Duplicate Manager names" is something to take care with
- ini file customizations are lost
Pros:
- there can be advantages to recreating MQ objects (queues) in a newer release (internal memory allocations...but this could also be a negative in some situations)
- in major MQ migrations (like MQ v6 moving channel definitions from one table to 'their own MQ objects') there may be extreme cases where deleting the Manager and recreating is needed
- Major MQ product problems where the Manager will not start after "data migration" (that occurs during the first strmqm) and we have to delete the Manager and recreate
- It's never a bad thing to have the MQSC definition of your current Manager (and re-dump after any changes of config or new MQ object create) It would be a 'best practice' to have the MQSC script to recreate your Manager 'always handy'. Maybe your system fails and your regular system backups are bad...give me a new system and the MQSC script and we have the Manager recreated (about 98%) from where it was previously.
Focusing on the piece regarding just the "regular straight forward upgrade" vs "side by side migration"
I am not familiar with the distributed "multi-version install" to be able to compare there. I would guess that once the Manager is started at MQ V9, the same Manager could not be restarted at MQ v7.1 as the data is v9 format. So you would still have to "revert the Manager data" So then we are really talking about the time (and risk of problems) with the OS400 dltlicpgm/rstlicpgm processing. I do not see that as a major task in terms of time or risk.
Is time assessment is off? Are they thinking that they want to 'change versions' forwards or backwards in 5 seconds more then 15 minutes? SME has not seen this in the past as a concern. If shutdown of application jobs and programs is also part of the process as versions are changed then add your usual application shutdown time on top of that" Some folks plan for a full hour of ending their applications before the quiesce of the Manager. So that is the time frame I am used to dealing with. If someone wants 5 second switches, then I would expect that they would be in a more specific environment for high-reliability/availability (like multi-instance, or clustering with all resources available on multiple systems/Managers etc.)
------------------------------
Mark Womack
Advisory Software Engineer
IBM
Durham
9192546547
------------------------------
Original Message:
Sent: 12-27-2018 11:14 AM
From: Dermot Flaherty
Subject: MQ Version Upgrade on IBM i (or iSeries)
Mark,
Many, many thanks to you and the Rochester folk for providing such an amazingly quick, detailed and helpful response. Apart from a couple of details I'd like to check, it answers my question completely. Could you please post it here to the group so all can see it. I have a couple of questions on it but it would be better if I did that to the "public" discussion and then everyone can benefit.
Thanks, Dermot
------------------------------
Dermot Flaherty
MQ Solutions Architect
Contractor
Original Message:
Sent: 12-27-2018 09:35 AM
From: Mark Womack
Subject: MQ Version Upgrade on IBM i (or iSeries)
Hi Dermot / per the reply I returned directly to you, please see that I did speak to one of the Rochester MQ SMEs who provided some detail that I hope you'll find useful for this upgrade. Cheers, Mark
------------------------------
Mark Womack
Advisory Software Engineer
IBM
Durham
9192546547
Original Message:
Sent: 12-26-2018 06:12 AM
From: Dermot Flaherty
Subject: MQ Version Upgrade on IBM i (or iSeries)
Does anyone have any experience with upgrading MQ on IBM i ?
A customer wants to upgrade MQ on IBM i from V7.1 to V9. The IBM i OS is
at the right level for MQ V9, there are local IBM i applications (no TCP/IP Client Apps) connecting to the MQ server and there are MQ Channels connecting to non-IBM i Qmgrs. The plan is to quiesce the MQ system and perform the code upgrade. There is NO requirement for data migration (messages on queues) apart (of course) from Configuration data saved using the DMPMQMCFG Cl command.
So far so good.
Multi-version install is not supported on IBM i and the docs state clearly that you have 2 choices of MQ install in this situation - (a) a SLIP install which seems to be an installation in place which will replace the previous MQ code or (b) a side-by-side install which means (I think) that you install the new MQ in a different IBM i partition.
If you want to be able to test the new version and quickly fall-back to the previous level if you hit a problem (of any kind), you go the side-by-side install route. But this must mean that connected Qmgrs will have to change their CONNAME values to talk to the new Qmgr.
If you go the SLIP install route, then if you want to fall-back to the previous level of MQ code, you have to re-install MQ at whatever level and of course if the previous MQ was running at some level (V7.1 say) with some level of maintenance, then there is the issue of restoring MQ to the same code level that it was running at the time of the upgrade.
Can anyone offer some advice as to which of the above routes they would choose based on their experience ?
It strikes me that this particular problem on IBM i is almost identical to the situation on Distributed platforms before multi-version install so perhaps the answer is whatever approach (in-place or side-by-side) was considered best practice on Dist. before multi-version install was introduced.
All advice gratefully accepted.
------------------------------
Dermot Flaherty
MQ Solutions Architect
Contractor
------------------------------