2

We have 2 production queue managers, running on 7.5 MQ (out of service) that are being moved to a more supported 8.0.0.4 environment ...(same OS - RHEL). We've made the destination servers equivalent VMs to the sources; we have 4 total queue managers being moved ... two at one site, two at another, one at each site which is a full repository for a cluster that they support. The only material change being made is that the destination connection name details will be changing for all 4 queue managers. We need to do each SITE one at a time; thus, partial first, then full at one site, partial first and full second at other site.

In terms of the actual steps, assuming we're simply doing a dmpmqcfg to get the details of each queue manager, we'll simply create the new queue managers, import the objects (as is), and then make appropriate channel changes for cluster receiver channel connection details, once the connections to the respective full repositories are made. However, Are there any concerns when relocating a full repository (gotcha's) that anyone can think of? Obviously, we change the receivers first so that the remaining full repos can publish that information to the other partial repositories. But when moving a full repository, should we first update all partials to point to the existing (unmoved) full repository first, and then move the full repository that no one has an explicit definition for, or can we simply update the explicit cluster senders with the new connection details AFTER the target full repository is moved?

John Edelmann
  • 21
  • 2
  • Hi John, do you use DNS names today? is it possible to re-point the existing DNS names to the new server IP addresses as part of the migration? This would make things much easier for you, but then again you only have a total of four queue managers to deal with so even if you need to update the `CONNAME` values there is not much work. Is the existing MQ install 64 bit Linux? You can check this with the command `file /opt/mqm/bin/strmqm` it should tell you it is 32 bit or 64 bit. – JoshMc Jul 24 '18 at 22:17
  • I would also suggest for a longer term solution going with RHEL v7 and MQ v9.0.0.4. If you do go with v8 you should go to 8.0.0.10. – JoshMc Jul 24 '18 at 22:18
  • Thanks Josh ... actually this is an interim step to moving this work load to MQ Appliances at 9.0 yes... – John Edelmann Jul 25 '18 at 02:29
  • And we cannot actually use DNS changes because we have existing queue managers on the target systems that need to survive following the arrival of the migrated qmgrs. At which point it might be 1/2 doz one - 6 the other deciding which qmgr env to impact by changing the connection names. – John Edelmann Jul 25 '18 at 02:49
  • You can always add CNAME (alias) records, so you don't have to change the name of the new destination system just add a alias to it that matches the old name. But the other thing to consider is if they are already 64bit and you just want to move them to new linux servers you can just tar up the qmgrs/QMNAME and log/QMNAME directories, untar them on the new system and add a stanza to the mqs.ini, when you start it up it will migrate from 7.5 to v8 just as if you had done a upgrade on the original server. – JoshMc Jul 25 '18 at 03:02
  • If you migrated like that then it is just a matter of on the PR/FR updating the CONNAME of the queue manager's own CLUSRCVR and on the explicit CLUSSDRs that point to that queue manager. No need to worry about backing up messages on queues, properly removing queue managers from the cluster and adding them back in, etc since the QMID of the qmgrs will remain the same. – JoshMc Jul 25 '18 at 03:18

0 Answers0