| Author |
Message
|
| mqtablet |
 Posted: Thu Apr 26, 2012 12:04 pm Post subject: dspmq on MQ v7.1 |
 |
|
Acolyte
Joined: 09 Jun 2009
Posts: 71
|
Any idea about how to use the dspmq command to find out all the queue managers of all available instances in a given MQ server?
Below are the options which can be used with dspmq
| Code: |
Usage: dspmq [-n] [-m QMgrName] [-o status | -s] [-o default]
[-o standby] [-o installation] [-x]
-m Queue manager name.
-n Suppress translation of output strings.
-o all
Display all status information for the queue managers.
-o status
Display the operational status of the queue managers.
-o default
Display whether any of the queue managers are the default.
-o standby
Display whether a queue manager currently permits a standby instance.
-o installation
Display the installation details of the queue managers.
-s Display the operational status of the queue managers.
-x Display information about instances of queue managers.
|
My concern now is -
1. When we have multiple instances of MQ with different installation names in a single computer, and run the dspmq command - it lists only the queue managers available in the primary installation.
2. If I have queue managers in other installations, any idea what is the command to list the queue managers in this second installation with dspmq command?
If I use the command -
| Code: |
| dspmq -o installation |
, it is showing the queue manager names present in the primary installation and the installation instance name. How do I find out the queue manager names of other instance? May be a simple command which I'm unable to figure out.. 
Thanks. |
|
| Back to top |
|
 |
| mqtablet |
| Posted: Thu Apr 26, 2012 12:13 pm Post subject: |
|
|
Acolyte
Joined: 09 Jun 2009
Posts: 71
|
| Code: |
C:\>dspmq -o all
QMNAME(DFLTQMGR) STATUS(Running) DEFAUL
T(no) STANDBY(Not permitted) INSTNAME(INST1) INSTPATH(C:\Program Files\IBM\
WebSphere MQ) INSTVER(7.1.0.0)
QMNAME(MQVDEV01) STATUS(Ended normally)
DEFAULT(no) STANDBY(Not applicable) INSTNAME(INST1) INSTPATH(C:\Program Fi
les\IBM\WebSphere MQ) INSTVER(7.1.0.0)
|
In the same machine, I have another instance of MQ 7.1 with installation name as 'INST2' and has a queue manager MQVDEV02.
This information is not being displayed when I run dspmq -o all  |
|
| Back to top |
|
|
| mqtablet |
| Posted: Thu Apr 26, 2012 12:24 pm Post subject: |
|
|
Acolyte
Joined: 09 Jun 2009
Posts: 71
|
A couple of more questions, sorry for multiple posts
1. I tried to create a queue manager in INST2 with the name of the queue manager which is present in INST1. It did not allow me.
So, what is the point of having multiple installations if I cannot have the same queue manager name in different instances? (In SQL, I can create databases with same name in different instances).
2. If I look from a migration perspective, say I have fix pack 7.1.0.1 (later) in INST1 and when there is a new fix pack by IBM, say 7.1.0.2 - I want to apply the latest fix pack 7.1.0.2 to INST2, create the same queue manager as INST1 and migrate - this is not possible as it is not allowing me to create the queue manager which is present in INST1 with same name in INST2.
Speaking at basics - What is the use of multiple installations of MQ in a server if I cannot have the same queue manager created in each instance? It is as good as having 2 different queue managers in the same installation. (I've read in infocenter that the applications can connect to the queue managers by specifying the instance name). So, this point is valid if we need to differentiate two queue managers with the same name in the same machine (by the installation name and connect the application to the appropriate instance). |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Apr 26, 2012 12:30 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
the point of separate installations is to allow you to install separate versions of WebSphere MQ, not create separate logical instances.
There's no good reason ever to create two queue managers with the exact same name. Ever. In any case, in any environment, anywhere. |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Apr 26, 2012 12:45 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| mqtablet wrote: |
| So, what is the point of having multiple installations if I cannot have the same queue manager name in different instances? (In SQL, I can create databases with same name in different instances). |
It is good that you cannot have 2 qmgrs of the same name on the same machine. It can only lead to trouble.
| Quote: |
| I want to apply the latest fix pack 7.1.0.2 to INST2, create the same queue manager as INST1 and migrate - this is not possible as it is not allowing me to create the queue manager which is present in INST1 with same name in INST2. |
To meet this requirement you can update your INST2 to 7.1.0.2, and then use the setmqm command.
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r1/topic/com.ibm.mq.doc/fa16045_.htm
Also search the information center for setmqm, and read the surrounding pages. (Please no-one mention PDFs!! )
| Quote: |
| I've read in infocenter that the applications can connect to the queue managers by specifying the instance name. |
Can you post the link you were reading, please? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Apr 26, 2012 12:49 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20703
Location: LI,NY
|
 you don't promote a qmgr from one environment to the other.
you build a new qmgr in the environment, or you migrate it from one version to the other...
In the realm of the cloud of infinite possibilities, there is nothing that prevents you from building up your own duplicated cloud version, tear it down and rebuild it again. Just don't expect to send any real traffic through it... that might throw a huge wrench into the works
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqtablet |
| Posted: Thu Apr 26, 2012 12:51 pm Post subject: |
|
|
Acolyte
Joined: 09 Jun 2009
Posts: 71
|
| mqjeff wrote: |
| the point of separate installations is to allow you to install separate versions of WebSphere MQ, not create separate logical instances.. |
This makes sense.
| mqjeff wrote: |
There's no good reason ever to create two queue managers with the exact same name. Ever. In any case, in any environment, anywhere. |
We never do. I wanted to try whether it works. Because what I thought was, say
1. Inst1 has qmgr QM1 with 7.1.0.0
2. Applications are currently using QM1, Inst1.
3. New installation - Inst2 in the same server - 7.1.0.1.
4. Create a new queue manager in Inst2 with the same name - QM1
5. Connect the applications by specifying Inst2 - QM1
6. If application works fine without issues, migration to 7.1.0.1 successful. Stop the QM1 in Inst1
So that migration can be done to QM1 Inst2 or reverted back in case of issues to QM1 Inst1 - just by making changes at MQ server about the default (Primary) instance so that no change ever needed at the application side (no change in host name, port, channel.. blah blah blah).
Only change is the change that we do, which is change the primary instance of installation by setmqinst command. Seems easy from a migration perspective.
By the any any info on the dspmq all queue managers of all instances stuff? Thanks Jeff. |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Apr 26, 2012 1:00 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| mqtablet wrote: |
| 5. Connect the applications by specifying Inst2 - QM1 |
The MQCONN call has not changed.. you still specify only a qmgr name. |
|
| Back to top |
|
|
| mqtablet |
| Posted: Thu Apr 26, 2012 1:09 pm Post subject: |
|
|
Acolyte
Joined: 09 Jun 2009
Posts: 71
|
| mvic wrote: |
| The MQCONN call has not changed.. you still specify only a qmgr name. |
Sorry, my mistake. What I meant initially was
Inst1 - primary = yes, has QM1, 7.1.0.0
Inst2 - primary = no, has QM1, 7.1.0.1
When app connects specifying QM1 it connects to the instance of Inst1.
Now I change the inst modes at MQ layer as below
Inst1 - primary = no, has QM1, 7.1.0.0
Inst2 - primary = yes, has QM1, 7.1.0.1
When app connects specifying QM1, it should connect to the queue manager QM1 in instance Inst2.
So that we can avoid migration issues. For any reason, if the app finds issues - no change at app side. Just change back the Inst1 to be the primary and the app connects back to QM1 of Inst1. (Just thought of, like a DNS name change pointing from one server to another server) |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 26, 2012 2:12 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqtablet wrote: |
| So that we can avoid migration issues. For any reason, if the app finds issues - no change at app side. Just change back the Inst1 to be the primary and the app connects back to QM1 of Inst1. (Just thought of, like a DNS name change pointing from one server to another server) |
It's a great plan; shame it won't work.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Apr 26, 2012 10:28 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5853
Location: UK
|
| mqjeff wrote: |
There's no good reason ever to create two queue managers with the exact same name. Ever. In any case, in any environment, anywhere. |
Absolute nonsense. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Fri Apr 27, 2012 12:13 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2602
Location: The Netherlands (Amsterdam)
|
dspmq should show ALL QueueManagers without regard of version.
so you mention having two 7.1.0.0 installs and one QMgr is not shown...
report it as a problem to IBM.
on application connectivity: from 7.1 the MQ libraries are version and installation aware and will pass on requests to other installations if the Queuemanager does not belong to the installation your application points to...
If you still have one install prior to 7.1 (officially this can only be 7.0.1.6 or up...) then that installation is always the primary and not aware of other installs, but does report the QMgrs as being present, just not available...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Apr 27, 2012 3:26 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
| mqjeff wrote: |
There's no good reason ever to create two queue managers with the exact same name. Ever. In any case, in any environment, anywhere. |
Absolute nonsense. |
Are you happier if i qualify it with "at the same time"?
backup qmgrs et. al being perfectly reasonable, I agree.
two queue managers at the same time in the same company with the exact same name is nothing more than a recipe for trouble, on the order of "whoops, who committed the indoubt messages on the wrong channel" |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Apr 27, 2012 3:45 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5853
Location: UK
|
I really don't see your problem. We have a whole bunch of DR queue managers with same names as production QMs.
The DNS names point to the active site. The standby ones (which are kept running for ease of adminstration) have no channels active, other than for admin use.
I agree that you should not connect two QMGRs of the same name to any application or to any other QM at the same time. We never do that. |
|
| Back to top |
|
|
| rammer |
| Posted: Fri Apr 27, 2012 4:13 am Post subject: |
|
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
| zpat wrote: |
| I really don't see your problem. We have a whole bunch of DR queue managers with same names as production QMs. |
Agreed |
|
| Back to top |
|
|
|
|
