ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexIBM MQ Installation/Configuration SupportPractice for MQ upgrade

Post new topicReply to topic
Practice for MQ upgrade View previous topic :: View next topic
Author Message
ftdmnt1600
PostPosted: Fri Jul 20, 2018 12:25 am Post subject: Practice for MQ upgrade Reply with quote

Newbie

Joined: 20 Jul 2018
Posts: 3

I am working on a project of upgrading MQ 8 to MQ9.

- QM A is existing MQ8, in use, connecting to remote QM X

- I created new v9 QM, also named A, as it's supposed to replace the old A


Problem is, old QM A will exist for months, as there are a few projects running on it, and I need to test the MQ objects ( queues / channels ) on new QM A

Question is, what's the best practice for this case? new QM has same name with old QM
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Sun Jul 22, 2018 3:52 pm Post subject: Reply with quote

Padawan

Joined: 25 Mar 2003
Posts: 1907
Location: Melbourne, Australia

You are already deviating from best practice onto a path of pain and suffering. Never create a qmgr with the same name as an existing qmgr. Use a new name, use it for shake-out testing, and migrate the apps to use it.

If the same name must be retained, totally isolate the new qmgr instance, and do a big-bang cutover (shutdown and disable the old instance, then start up / start channels on the new instance).
_________________
Glenn
Back to top
View user's profile Send private message
ftdmnt1600
PostPosted: Mon Jul 23, 2018 4:21 am Post subject: Reply with quote

Newbie

Joined: 20 Jul 2018
Posts: 3

gbaddeley wrote:
You are already deviating from best practice onto a path of pain and suffering. Never create a qmgr with the same name as an existing qmgr. Use a new name, use it for shake-out testing, and migrate the apps to use it.

If the same name must be retained, totally isolate the new qmgr instance, and do a big-bang cutover (shutdown and disable the old instance, then start up / start channels on the new instance).


Many thanks for the reply.

Application is using the existing MQ server, in parallel I am building the new server, ideally we should remain the MQ objects the same ( QM name, channel, etc) , which brings minimal change to application.

Problem is, existing MQ server A connects to remote MQ server B, new built MQ server A should connects to same remote MQ server, then we have trouble on the channel name and transit queue etc ...
Back to top
View user's profile Send private message
rammer
PostPosted: Mon Jul 23, 2018 4:47 am Post subject: Reply with quote

Partisan

Joined: 02 May 2002
Posts: 359
Location: England

You have to create new channels etc no other way around it... In which case maybe best to follow best practice and do not add another QMGR with the same name. Either way new channels etc are needed...
Back to top
View user's profile Send private message
bruce2359
PostPosted: Mon Jul 23, 2018 7:08 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8210
Location: US: west coast, almost. Otherwise, enroute.

rammer wrote:
You have to create new channels etc no other way around it... In which case maybe best to follow best practice and do not add another QMGR with the same name. Either way new channels etc are needed...

New channels? What alternative is there for a new qmgr?
_________________
I would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Mon Jul 23, 2018 4:06 pm Post subject: Reply with quote

Padawan

Joined: 25 Mar 2003
Posts: 1907
Location: Melbourne, Australia

ftdmnt1600 wrote:
Many thanks for the reply.
Application is using the existing MQ server, in parallel I am building the new server, ideally we should remain the MQ objects the same ( QM name, channel, etc) , which brings minimal change to application.
Problem is, existing MQ server A connects to remote MQ server B, new built MQ server A should connects to same remote MQ server, then we have trouble on the channel name and transit queue etc ...

Minimal change to application or trouble with channel names etc is not an excuse for compromising MQ best practice. You need to take time to design the best method for migration that will be supportable into the future. Regarding app changes, you should tell them exactly what needs to be changed, and ensure that they do it, and test.
_________________
Glenn
Back to top
View user's profile Send private message
ftdmnt1600
PostPosted: Tue Jul 24, 2018 9:05 pm Post subject: Reply with quote

Newbie

Joined: 20 Jul 2018
Posts: 3

gbaddeley wrote:
ftdmnt1600 wrote:
Many thanks for the reply.
Application is using the existing MQ server, in parallel I am building the new server, ideally we should remain the MQ objects the same ( QM name, channel, etc) , which brings minimal change to application.
Problem is, existing MQ server A connects to remote MQ server B, new built MQ server A should connects to same remote MQ server, then we have trouble on the channel name and transit queue etc ...

Minimal change to application or trouble with channel names etc is not an excuse for compromising MQ best practice. You need to take time to design the best method for migration that will be supportable into the future. Regarding app changes, you should tell them exactly what needs to be changed, and ensure that they do it, and test.


thanks I will go through this with team
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexIBM MQ Installation/Configuration SupportPractice for MQ upgrade
Jump to:



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.