| Author |
Message
|
| alastor52 |
 Posted: Tue Apr 15, 2008 5:02 am Post subject: Cluster Quandary |
 |
|
Apprentice
Joined: 09 May 2006
Posts: 37
|
Here is my setup:
QM_1 & QM_2 on Solaris, QM_A on AIX, all MQ version 6. All three QMs are in a cluster - CLUST1.
Q_IN is defined on QM_1 and is clustered with default bind - Not fixed.
QM alias QM_A is defined on QM_A with RemoteQMgrName blank.
Vendor app APP connects to QM_A specifying QM_A in the connection and opening the connection using this command:
O_options = MQOO_OUTPUT + MQOO_FAIL_IF_QUIESCING;
MQOPEN(GHcon, &od, O_options, &Q->Hobj, &CompCode, &Reason);
Here is my problem:
When the vendor app starts it throws this error:
(MQOPEN on Queue Q_IN Failed with Reason 2085) which I know means it can't find the queue.
From the reading and searching I've done I was under the impression that if I defined a QM Alias with the name of the QM the connection was using then I could basically 'reset' the values used for name resolution. Since I've set RemoteQMgrName to blank, it was then my understanding that the QM would then look for the queue in the cluster. Obviously this is not working.
I can define an alias on QM_A for Q_IN and I can successfully put a message to the alias which shows up on Q_IN. However, when I have the vendor app point to the alias - Q_IN_A on QM_A it throws this error:
(MQOPEN on Queue Q_IN_A Failed with Reason 2082).
So how can I configure my Queue Managers to properly resolve the name of the cluster queue for an MQ Client application which is connecting and specifying a QM in the connection?
Thanks  |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Apr 15, 2008 5:07 am Post subject: Re: Cluster Quandary |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| alastor52 wrote: |
So how can I configure my Queue Managers to properly resolve the name of the cluster queue for an MQ Client application which is connecting and specifying a QM in the connection?
|
By making sure your cluster is working. In the setup you've described (unless I'm missing something) you have a client attached to QM_A, trying to put to a cluster queue hosted on QM_1. This shouldn't require any queue manager aliasing or anything like that. Any application always connects to a single queue manager (in this case QM_A), even if that queue manager happens to be a member of a cluster. The connection has no impact on name resolution.
What happens if you do a dis qc(Q_IN)? Which of the queue managers are the FRs? Are you certain all the cluster channels are running & the cluster names are spelt correctly throughout?
_________________
Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Tue Apr 15, 2008 5:11 am; edited 2 times in total |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Apr 15, 2008 5:08 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
There's a difference between the name of a queue manager in MQCONN than in MQOPEN.
In order to override the name of a queue manager in MQCONN, you have to play tricks with the client channel table (and have to *use* a client channel table).
In order to override the name of a queue manager in MQOPEN, you have to use a QREMOTE, not a QALIAS.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| alastor52 |
| Posted: Tue Apr 15, 2008 5:18 am Post subject: Re: Cluster Quandary |
|
|
Apprentice
Joined: 09 May 2006
Posts: 37
|
| Vitor wrote: |
What happens if you do a dis qc(Q_IN)? Which of the queue managers are the FRs? Are you certain all the cluster channels are running & the cluster names are spelt correctly throughout? |
Currently all three queue managers are full repositories. When I do 'dis qc(Q_IN)' on QM_A it returns:
Starting MQSC for queue manager QM_A.
dis qc(Q_IN)
1 : dis qc(Q_IN)
AMQ8409: Display Queue details.
QUEUE(Q_IN) TYPE(QCLUSTER)
ALTDATE(2008-04-14) ALTTIME(15.47.01)
CLUSDATE(2008-04-15) CLUSTER(CLUST1)
CLUSQMGR(QM_1) CLUSQT(QLOCAL)
CLUSTIME(08.32.53) CLWLPRTY(9)
CLWLRANK(0) DEFBIND(NOTFIXED)
DEFPRTY(0) DEFPSIST(NO)
DESCR( ) PUT(ENABLED)
QMID(QM_1_2007-11-19_16.45.09)
If I get rid of the QM alias on QM_A and have the app try and connect to the cluster queue I still get the error:
(MQOPEN on Queue Q_IN Failed with Reason 2085) |
|
| Back to top |
|
|
| alastor52 |
| Posted: Tue Apr 15, 2008 5:24 am Post subject: |
|
|
Apprentice
Joined: 09 May 2006
Posts: 37
|
| jefflowrey wrote: |
| In order to override the name of a queue manager in MQOPEN, you have to use a QREMOTE, not a QALIAS. |
Doesn't using a remote queue definition defeat the purpose of having a cluster and clustered queues? I intend to have Q_IN defined on both QM_1 & QM_2 for failover purposes. Or can a remote queue definition connect to a clustered queue through the cluster channels? |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Apr 15, 2008 5:28 am Post subject: Re: Cluster Quandary |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| alastor52 wrote: |
| Currently all three queue managers are full repositories. |
There is a recent post discussing why more than 2 FRs in a cluster is not a good idea. You may want to review it.
| alastor52 wrote: |
When I do 'dis qc(Q_IN)' on QM_A it returns:
Starting MQSC for queue manager QM_A.
dis qc(Q_IN)
1 : dis qc(Q_IN)
AMQ8409: Display Queue details.
QUEUE(Q_IN) TYPE(QCLUSTER)
ALTDATE(2008-04-14) ALTTIME(15.47.01)
CLUSDATE(2008-04-15) CLUSTER(CLUST1)
CLUSQMGR(QM_1) CLUSQT(QLOCAL)
CLUSTIME(08.32.53) CLWLPRTY(9)
CLWLRANK(0) DEFBIND(NOTFIXED)
DEFPRTY(0) DEFPSIST(NO)
DESCR( ) PUT(ENABLED)
QMID(QM_1_2007-11-19_16.45.09)
|
This shows the cluster is working (though I'd still look at that post on FRs). 
What happens if the app doesn't specify a queue manager at all in the open (the more normal coding)? Or perhaps a better question is why is it specifying a specific name? What requirement are you trying to achieve with this?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Apr 15, 2008 5:28 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| alastor52 wrote: |
| jefflowrey wrote: |
| In order to override the name of a queue manager in MQOPEN, you have to use a QREMOTE, not a QALIAS. |
Doesn't using a remote queue definition defeat the purpose of having a cluster and clustered queues? I intend to have Q_IN defined on both QM_1 & QM_2 for failover purposes. Or can a remote queue definition connect to a clustered queue through the cluster channels? |
QALIAS only has a queue name, it doesn't have an queue manager name. You can share a QREMOTE in a cluster.
Also, do not create more than two FRs. Nor less than two.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Apr 15, 2008 5:31 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| alastor52 wrote: |
| I intend to have Q_IN defined on both QM_1 & QM_2 for failover purposes. |
Do not use WMQ clustering for failover. There are endless discussion in here why that's not a good idea. You've found one of them.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| alastor52 |
| Posted: Tue Apr 15, 2008 5:38 am Post subject: Re: Cluster Quandary |
|
|
Apprentice
Joined: 09 May 2006
Posts: 37
|
| Vitor wrote: |
There is a recent post discussing why more than 2 FRs in a cluster is not a good idea. You may want to review it.
What happens if the app doesn't specify a queue manager at all in the open (the more normal coding)? Or perhaps a better question is why is it specifying a specific name? What requirement are you trying to achieve with this? |
The application connecting to QM_A is a vendor written application. I may or may not be able to get them to change it. I'm not sure why they are specifying a queue manager in the open. I'll try to find that post. Thanks! |
|
| Back to top |
|
|
| alastor52 |
| Posted: Tue Apr 15, 2008 5:46 am Post subject: |
|
|
Apprentice
Joined: 09 May 2006
Posts: 37
|
| jefflowrey wrote: |
| QALIAS only has a queue name, it doesn't have an queue manager name. You can share a QREMOTE in a cluster. |
I think I might be a bit confuzzled here. If you are talking about defining the Queue Manager Alias on QM_A, then yes, I was creating it as a QREMOTE. This wasn't working though. |
|
| Back to top |
|
|
| alastor52 |
| Posted: Tue Apr 15, 2008 9:50 am Post subject: |
|
|
Apprentice
Joined: 09 May 2006
Posts: 37
|
| jefflowrey wrote: |
There's a difference between the name of a queue manager in MQCONN than in MQOPEN.
In order to override the name of a queue manager in MQCONN, you have to play tricks with the client channel table (and have to *use* a client channel table).
In order to override the name of a queue manager in MQOPEN, you have to use a QREMOTE, not a QALIAS. |
The vendor app uses this command to connect to QM_A:
MQCONN(QMNAME, &GHcon, &CompCode, &Reason);
where QMNAME is set to 'QM_A' and this is okay. The issue is that the MQOPEN command specifies a queue manager when it executes. So, if I understand you correctly, I can override the name of the queue manager by creating a queue manager alias on QM_A:
DEFINE QREMOTE(QM_A) RNAME(' ') RQMNAME(' ')
so during name resolution the queue manager specified in the MQOPEN statement, 'QM_A', will be replaced by ' '. Then the queue manager will look to the cluster for the queue. Is this correct? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Apr 15, 2008 9:57 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
No, it's what they specify on MQOPEN that's the issue.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| alastor52 |
| Posted: Tue Apr 15, 2008 10:10 am Post subject: |
|
|
Apprentice
Joined: 09 May 2006
Posts: 37
|
| jefflowrey wrote: |
| No, it's what they specify on MQOPEN that's the issue. |
Well, in the Queue Manager Clusters guidebook when it is explaining Queue-manager aliases it specifically states:
"A queue-manager alias can be used to remap the queue-manager name specified in an MQOPEN call to another queue-manager."
So, if I DEFINE QREMOTE(QM_A) RNAME(' ') RQMNAME(' ') then on the MQOPEN shouldn't it set the queue manager name to ' '?
Then according to the Application Programming Guide where is discusses Name Resolution, in the table it shows that when it encounters a queue manager alias that it will perform name resolution again with ObjectQMgrName set to RemoteQMgrName. If the queue manager name is blank then the table indicates that the queue manager will look for the queue in the cluster.
So what am I missing?
Last edited by alastor52 on Tue Apr 15, 2008 10:31 am; edited 1 time in total |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Apr 15, 2008 10:29 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
No.
You need to define a queue manager alias that overwrites whatever they specify on the MQOPEN. NOT on the MQCONN.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| alastor52 |
| Posted: Tue Apr 15, 2008 10:33 am Post subject: |
|
|
Apprentice
Joined: 09 May 2006
Posts: 37
|
| jefflowrey wrote: |
No.
You need to define a queue manager alias that overwrites whatever they specify on the MQOPEN. NOT on the MQCONN. |
Okay, sorry, I wasn't being clear. The vendor app specifies QM_A as the queue manager in BOTH the MQCONN and the MQOPEN. |
|
| Back to top |
|
|
|
|
