| Author |
Message
|
| sebastia |
 Posted: Thu Feb 19, 2009 9:29 am Post subject: instaling MQ v7 on top of v6 |
 |
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
I cant find any place where it says explicitly
that to install MQ version 7
on top of an existing MQ version 6
you can do it without deleting the previous software and data.
Any pointer ? Seb. |
|
| Back to top |
|
 |
| sebastia |
| Posted: Thu Feb 19, 2009 9:48 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
What I have in "Migration Guide", page 12 is :
When you have upgraded from a previous version of WebSphere MQ to
WebSphere MQ Version 7.0 on an individual computer :
– On distributed, then any queue manager on that computer is migrated to WebSphere MQ Version 7.0 when you start the queue manager. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 19, 2009 10:27 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastia wrote: |
| – On distributed, then any queue manager on that computer is migrated to WebSphere MQ Version 7.0 when you start the queue manager. |
That's as explicit as it gets. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sebastia |
| Posted: Thu Feb 19, 2009 10:39 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
I agree, Vitor, it is quite enough, at least for me,
but my customer complains about
what shall happen to its production envirironment ...
Guess we shall have a test on "dev" envir first,
and maybe they shall trust me a bit more after it !
Zkx. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 19, 2009 10:59 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastia wrote: |
I agree, Vitor, it is quite enough, at least for me,
but my customer complains about
what shall happen to its production envirironment ... |
I was (perhaps unusually) serious - that's as explicit as it gets:
| Quote: |
| any queue manager on that computer is migrated to WebSphere MQ Version 7.0 when you start the queue manager |
Note "is migrated"; not "might be migrated", "is probably migrated", "should be migrated". This is an explicit statement from the people who make the software.
| sebastia wrote: |
Guess we shall have a test on "dev" envir first,
and maybe they shall trust me a bit more after it !
|
Never a bad idea, but it does happen. Even in the production environment of paranoid users.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Feb 19, 2009 7:16 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
It depends on your platform.
And the Migration Guide is very explicit on this.
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzao.doc/mi10910_.htm
| Quote: |
Coexistence
For the purposes of this section, coexistence is defined as the ability of two or more different versions of WebSphere MQ to function on the same computer. Two or more different versions of WebSphere® MQ cannot coexist on the same computer, except for WebSphere MQ for z/OS® where multiple different versions can coexist in a limited number of scenarios.
Coexistence on WebSphere MQ for AIX
WebSphere MQ for AIX® Version 7.0 does not coexist with previous versions of WebSphere MQ. You must migrate from either WebSphere MQ Version 5.3 or WebSphere MQ Version 6.0 to WebSphere MQ Version 7.0. You do not have to uninstall your current version before installing WebSphere MQ Version 7.0 because the installation process does it for you. Coexistence on WebSphere MQ for HP-UX
WebSphere MQ for HP-UX Version 7.0 does not coexist with previous versions of WebSphere MQ. You must migrate from either WebSphere MQ Version 5.3 or WebSphere MQ Version 6.0 to WebSphere MQ Version 7.0. If you are migrating from a previous version of WebSphere MQ for HP-UX, you must uninstall your current version before installing WebSphere MQ Version 7.0.
Coexistence on WebSphere MQ for i5/OS
WebSphere MQ for i5/OS® Version 7.0 does not coexist with previous versions of WebSphere MQ.
Coexistence on WebSphere MQ for Linux
WebSphere MQ for Linux® Version 7.0 does not coexist with previous versions of WebSphere MQ. You must migrate from either WebSphere MQ Version 5.3 or WebSphere MQ Version 6.0 to WebSphere MQ Version 7.0. If you are migrating from a previous version of WebSphere MQ for Linux, you must uninstall your current version before installing WebSphere MQ Version 7.0.
Coexistence on WebSphere MQ for Solaris
WebSphere MQ for Solaris Version 7.0 does not coexist with previous versions of WebSphere MQ. You must migrate from either WebSphere MQ Version 5.3 or WebSphere MQ Version 6.0 to WebSphere MQ Version 7.0. If you are migrating from a previous version of WebSphere MQ for Solaris, you must uninstall your current version before installing WebSphere MQ Version 7.0.
Coexistence on WebSphere MQ for Windows
WebSphere MQ for Windows® Version 7.0 does not coexist with previous versions of WebSphere MQ. You must migrate from either WebSphere MQ Version 5.3 or WebSphere MQ Version 6.0 to WebSphere MQ Version 7.0. You do not have to uninstall your current version before installing WebSphere MQ Version 7.0 because the installation process does it for you.
Coexistence on WebSphere MQ for z/OS
You must take a number of factors into consideration when WebSphere MQ Version 7.0 for z/OS coexists with previous versions of WebSphere MQ for z/OS. |
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 20, 2009 12:04 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
But irrespective of this, the queue manager is migrated automatically on startup.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sebastia |
| Posted: Fri Feb 20, 2009 12:12 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Peter - this is exactly the sentence(s) I needed. Thanks a lot.
Vitor - it is not the queue manager that worries me and my client,
but the fact that (in production envir) we have to do (or not) :
1) save configuration (objects)
2) stop the service,
3) save the configuration (ini files)
4) uninstall software
5) install software
6) create qmgrs
7) browse ini files
create objects
You teached me that (6-7- has not to be done - qmgr is migrated automatically - good.
Now, even (4) has not to be done, as we are using AIX.
Cheers. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 20, 2009 12:16 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastia wrote: |
| Now, even (4) has not to be done, as we are using AIX. |
Nor do the other steps. If you re-run the configuration you could lose any data held in the queues. Leave the objects as they are and let the automatic process handle them.
The important point is the system level backup prior to the upgrade. If for any reason you need to revert to v6, the newly created v6 queue managers will not be able to interpret the logs & objects of v7. So to revert you need to restore the file system.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sebastia |
| Posted: Fri Feb 20, 2009 12:22 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
a) data in queue - yes, I expected them to be empty,
but maybe it is not the case (!!!???)
b) save filesystem - yes, we shall do that.
Thanks for the clues.
I really appreciate the opinion interchange(s)
( )
Sebastian. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 20, 2009 12:23 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastia wrote: |
a) data in queue - yes, I expected them to be empty,
but maybe it is not the case (!!!???) |
Not the SYSTEM queues. And why take the risk when there's an easy alternative?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Feb 20, 2009 12:30 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I find the idea that you can't install the new version alongside the current version of MQ on a large, expensive AIX platform somewhat ridiculous.
These things are not personal computers - or are they? |
|
| Back to top |
|
|
| sebastia |
| Posted: Fri Feb 20, 2009 12:33 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
mr Vitor : if there is an easy path, I shall follow it, of course.
But asking (clever) questions will give a better taste to my job.
So here's the next question :
Do you think we shall be worried about system queues contents,
in the fact that we are migrating (production)
from mq v6 to v7 ?
What kind of informtaion would we be able to lose otherwise ?
cluster ?
security ?
I agree I am an ignorant about system queues usage
(except as models for object creation)
Seb. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 20, 2009 12:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastia wrote: |
Do you think we shall be worried about system queues contents,
in the fact that we are migrating (production)
from mq v6 to v7 ?
What kind of informtaion would we be able to lose otherwise ?
cluster ?
security ?
|
You should never worry about system queues, even in production. Indeed it's better to ignore them and let the queue manager handle them. I tend not to use them even as models and set up my own.
I also find it more convienient as SYSTEM.DEAD.LETTER.QUEUE doesn't show up in MQExplorer by default when DEAD.LETTER does.
Cluster and security are indeed 2 things you'd need to recreate if you recreate the queue managers as indicated in your step 6. Again, I wouldn't bother especially.
Of course, if your queue managers are in a cluster there was of course a step 2a in your plan "Remove qmgrs from cluster", wasn't there...?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sebastia |
| Posted: Fri Feb 20, 2009 12:49 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
I totally agree : the system object are not very good as models.
I was told to "tailor" them to my customer's profile
changing MAXDEPTH, and MAXMSGL, etc etc
so all future created objects shall have these properties,
and later found that the command "strmqm" has a flag that destroys all :
"" -c recreates the system objects with the default values ""
Ok - here's the new "to-do" list :
1] save configuration (objects)
2] remove qmgrs from cluster
3] stop qmgrs
4] save the configuration (ini files)
5] uninstall software
6] install software
7] create qmgrs
8] browse ini files
9] create objects
10] create the cluster
"now that I know the answers, they change the questions ..." |
|
| Back to top |
|
|
|
|
