Author |
Message
|
sfari |
Posted: Tue May 16, 2006 3:24 am Post subject: Migrate non Repository Cluster QMs to V6 |
|
|
Centurion
Joined: 15 Apr 2003 Posts: 144
|
We are planning to upgrade MQ to V6 in the next few month on all our systems.
A part of our environment are 2 Solaris QMs (5.3 CSD10) building a cluster with 2 z/OS QMs (5.3.1). The repositories are on the z/OS QMs.
I read that the repository QMs shall be upgraded first. But we planned to upgrade MQ on Solaris first (because other non technical reasons).
Has somebody already tried to upgrade the non repository QM first? Does this work? If not what are the problems? What can I do to realize our plan, is it an option to move the repositories to Solaris? |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue May 16, 2006 3:28 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
If you don't migrate the repositories first, and you add any v6 specific information to any of the objects in the cluster or to the cluster channels, you run the risk of corrupting your repositories. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
sfari |
Posted: Tue May 16, 2006 3:43 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2003 Posts: 144
|
So is it no risk if I don't add v6 specific information to the objects? Is not already the conversion of the channels to MQ objects a problem? |
|
Back to top |
|
 |
Ivans |
Posted: Tue May 16, 2006 4:21 am Post subject: |
|
|
Apprentice
Joined: 03 Jan 2006 Posts: 48 Location: Hursley
|
Quote: |
If you don't migrate the repositories first, and you add any v6 specific information to any of the objects in the cluster or to the cluster channels, you run the risk of corrupting your repositories. |
What type of corruption? How great is the risk? Please explain further. I'm not (yet?) aware of any corruption caused by mixing V5.3 and V6 queue managers in a cluster, regardless of the full repository configuration.
If you upgrade partial repositories first and you are NOT using the new cluster workload features -> No problem.
If you upgrade partial repositories first and you ARE using the new cluster workload features -> You run the risk of the cluster workload balancing algorithm on the V6 queue managers using a default value for a new attribute instead of the actual value (e.g. CLWLRANK=0 instead of, say, CLWLRANK=3) in some situations. No corruption, no abends, just some rare workload balancing skewing.
Well, that's the way it was designed anyhow
Cheers,
Ian |
|
Back to top |
|
 |
sfari |
Posted: Tue May 16, 2006 4:49 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2003 Posts: 144
|
Hi Ian
Thanks for your answer. Does this mean the way we have planned with upgrading first the partitial repositories is no risk to do? Have you done this? Or is there somebody else with experiences in this topic?
Thanks
Silvano |
|
Back to top |
|
 |
Ivans |
Posted: Tue May 16, 2006 5:22 am Post subject: |
|
|
Apprentice
Joined: 03 Jan 2006 Posts: 48 Location: Hursley
|
I have done this with mixed platform queue managers, using the new attributes (or not using them), with no problem. I do recommend testing any sort of migration procedure, whether it involves clustering or not, before rolling it out in production though.
Cheers,
Ian |
|
Back to top |
|
 |
sfari |
Posted: Tue May 16, 2006 6:22 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2003 Posts: 144
|
Thank you very much for the answer. Of course I will make tests before enrolling the new version in production. I just wanted to be sure not to setup a test environment in a way it will anyway not work.
Thanks
Silvano |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue May 16, 2006 7:31 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Perhaps the v5.3 repository data structures are more flexible than the 5.2 were.
The v5.2 cluster repositorys would get corrupted if you enabled SSL on any channels in the cluster, because the 5.2 repository data structures did not have room to hold this data. I would expect there to be a risk of similar corruption if you added, for example, channel compression attributes to a cluster channel, or enabled accounting on a cluster queue.
If the cluster repository data structures in 5.3 have been made flexible enough to handle this new data, then this is a good thing, but I would be surprised if this were true for all CSD/FP levels of 5.3. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
wschutz |
Posted: Tue May 16, 2006 7:35 am Post subject: |
|
|
 Jedi Knight
Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired)
|
I believe the v5.3 repos will gracefully ignore any v6 attributes they don't understand..... _________________ -wayne |
|
Back to top |
|
 |
vennela |
Posted: Tue May 16, 2006 8:32 am Post subject: |
|
|
 Jedi Knight
Joined: 11 Aug 2002 Posts: 4055 Location: Hyderabad, India
|
wschutz wrote: |
I believe the v5.3 repos will gracefully ignore any v6 attributes they don't understand..... |
From when will they start not ignoring them?
Once they are upgraded or after upgrade whenever the first time a cluster member talks to it. |
|
Back to top |
|
 |
sfari |
Posted: Wed May 17, 2006 10:27 pm Post subject: |
|
|
Centurion
Joined: 15 Apr 2003 Posts: 144
|
Quote: |
Once they are upgraded or after upgrade whenever the first time a cluster member talks to it. |
@vennela what do you mean with this? |
|
Back to top |
|
 |
wschutz |
Posted: Thu May 18, 2006 1:15 am Post subject: |
|
|
 Jedi Knight
Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired)
|
vennela wrote: |
wschutz wrote: |
I believe the v5.3 repos will gracefully ignore any v6 attributes they don't understand..... |
From when will they start not ignoring them?
Once they are upgraded or after upgrade whenever the first time a cluster member talks to it. |
Once upgraded, V6 repos's would store any NEW publications containing v6 attributes. _________________ -wayne |
|
Back to top |
|
 |
|