| Author |
Message
|
| bprasana |
 Posted: Thu Oct 17, 2013 10:48 pm Post subject: Migration plan for MQ from v6 to v7 |
 |
|
Disciple
Joined: 18 Apr 2005
Posts: 179
|
Hey guys,
I saw a couple of topics regarding this in the forum but i have a more generic set of queries.
lets say there are 30 applications interacting with WMQ v6 Qmgrs, which are in cluster and a cluster of gateway Qmgrs. The applications ranges from java,c,.net etc. Qmgrs are all deployed in Solaris.
Its been very difficult to convince all the 30 applications to move at the same time so we need a more granular approach.
Given these facts
1. What should we consider as parameters for migration?
2. Can we migrate 1 Qmgr at a time? what are the possible issues if we do that?
3. Can migrate all Q mgrs to v7.x in a different server, and connect v6 Qmgrs to v7 and change all local Qs in v6 to remote Qs? when the client is ready to migrate he can connect to V7 Qmgr and we retire the v6 Qmgr?
4. What other strategies have you followed in the past for migration? |
|
| Back to top |
|
 |
| karthik_ps |
| Posted: Mon Oct 21, 2013 4:15 am Post subject: |
|
|
Apprentice
Joined: 10 Dec 2008
Posts: 43
|
Hi ,
We have recently upgraded the MQ version from 6 to 7 along with MB from 6 to 8.0.0.2. We dont have MQ cluster instead we are using p2p. While migrating MQ, we had gone for a complete outage (about 4 hrs). To install MQ7, pre requistie fix pack (MB 6.1.0.10) has to be installed first. Then we uninstalled MQ 6 by removing the packages and installed MQ 7. After installation, we had refreshed all queue managers(strmqm -c) and started it. It can be done parallely. However, one of the queue manager log file got corrupted during the queue manager start in MQ7. Then, we deleted that queue manager and recreated it in MQ 7. As we had already taken queue manager backup (using saveqmgr script), we were able to restore all of its objects in minutes in the newly created queue manager. Though i could not answer your questions, i take this oppurtunity to share my experience.
Regards,
Karthik |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Oct 21, 2013 4:29 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Don't forget to save the authorities as well as the queue and other object definitions.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| bprasana |
| Posted: Mon Oct 21, 2013 7:43 am Post subject: Thanks |
|
|
Disciple
Joined: 18 Apr 2005
Posts: 179
|
Thanks guys! Point noted.
We have installed mQ v7 in a brand new server and the applications are being asked to connect to this server instead of old v6 server. We are creating the v7 QMgrs with the same name as v6.
We have these broad scenarios
1. one QM being used by ONLY one application.
- this is easy to migrate
2. one QM being used by MANY applications
- in this case, is there a way to migrate only those applications which are ready to migrate and leave those behing which are not ready?
3. Many QMs being used by one application
- this should be easy to migrate too
I am looking for some strategies for Point 2. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Mon Oct 21, 2013 9:59 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
For your #2 point, if the applications are on the same machine as the Qmgr, then it is all or nothing.
If the applications are remote and connecting via MQ Client, then it is the level of the client that matters.
What do you mean "migrate the applications"? recompile and link?
Before migrating, stop the Qmgr and TAR up the:
/var/mqm/qmgrs/<Qmgr>
/var/mqm/log/<Qmgr>
/var/mqm/mqs.ini
files. If you need to roll back, just:
- delete the Qmgr
- uninstall WMQ
- install WMQ at the previous level
- unTAR the backup
- fire that puppy up
Recently, I upgraded a Qmgr to 7.5.0.2. The WAS that connected to it was installed at 7.0.0.0 but had lots of maintenance. It didn't connect! Turns out there was a bug at that level of MQ client that got packaged and WAS did not push the update down to all the RARs. Here is the fix for WAS |
|
| Back to top |
|
|
| Tibor |
| Posted: Tue Oct 22, 2013 3:01 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| An experience: because you have many connecting applications, and if some of them handle RFH2 header, MQ v7 upgrade can cause problems. You should consider the testing for appropriate setting of PROPCTL parameter on local queues. |
|
| Back to top |
|
|
| bprasana |
| Posted: Tue Oct 22, 2013 3:29 am Post subject: Thanks |
|
|
Disciple
Joined: 18 Apr 2005
Posts: 179
|
Hey guys thanks a lot
Yes all applications interact using MQ client.
Tibor- could you please elaborate on the issue you faced with MQRFH2 ? |
|
| Back to top |
|
|
| Tibor |
| Posted: Tue Oct 22, 2013 3:57 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
Some application were not able to get MQRFH2 header in PROPCTL(COMPAT) (=Compatibility) mode, only after it was changed to PROPCTL(FORCE) (=Force-to-MQRFH2). This behavior is coming for the changes of the MQ API v7, which can handle messages properties directly, and they are stored in an MQRFH2 header. There is an option for controlling property handling on application side by MQGMO_PROPERTIES_... settings as well.
More info here: http://pic.dhe.ibm.com/infocenter/wmqv7/v7r1/topic/com.ibm.mq.doc/mi20360_.htm |
|
| Back to top |
|
|
|
|
