|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
cluster queue showing up as put disabled |
« View previous topic :: View next topic » |
Author |
Message
|
senMQ |
Posted: Fri Jul 05, 2013 12:49 pm Post subject: cluster queue showing up as put disabled |
|
|
Acolyte
Joined: 14 Aug 2006 Posts: 66 Location: Palo Alto, CA
|
We have a MQ cluster with both UNIX and mainframe queue managers.
I created a new UNIX clustered queue manager with a bunch of clustered queues. I created the queues with put attribute as NO. I switched it to YES once the application team was ready to use this new queue manager.
Now, the ORDER queue's put attribute is showing up as NO in the mainframe queue manager. But, the PUT attributes of all the other queues from the unix queue manager is showing up as YES in the mainframe queue manager. Also, the PUT attribute is showing up as YES for the ORDER queue in all the other queue managers in the cluster.
To summarize, the mainframe application is able to put the message in to all the queues except for the ORDER queue as the put attributed is showing up as NO. All the other queue managers in the cluster are able to put messages into this ORDER queue. All the queue managers involved in this issue are partial repositories.
These are actions taken so far:
I removed the ORDER queue from the cluster and added it back again.
I deleted the queue and created it with put attribute as YES.
z/os admin ran the refresh cluster command on the mainframe queue manager.
None of the above steps resolved the issue.
Any thoughts on what I'm missing here? |
|
Back to top |
|
 |
bruce2359 |
Posted: Fri Jul 05, 2013 1:53 pm Post subject: Re: cluster queue showing up as put disabled |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
senMQ wrote: |
To summarize, the mainframe application is able to put the message in to all the queues except for the ORDER queue as the put attributed is showing up as NO. All the other queue managers in the cluster are able to put messages into this ORDER queue. All the queue managers involved in this issue are partial repositories.
These are actions taken so far:
I removed the ORDER queue from the cluster and added it back again.
I deleted the queue and created it with put attribute as YES.
z/os admin ran the refresh cluster command on the mainframe queue manager.
None of the above steps resolved the issue.
Any thoughts on what I'm missing here? |
Queues don't put-inhibit themselves. Something (like an application) or someone (like a system admin) put-inhibited the queue.
If a cluster queue is put-inhibited, it will not be chosen as a destination for puts - as long as there are other instances of the same queue elsewhere in the cluster.
If the put-inhibited queue is the only instance of the queue, then the put will fail, and the app will receive a put-inhibited ReasonCode.
Find out who or what is put-inhibiting the queue. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
senMQ |
Posted: Fri Jul 05, 2013 2:02 pm Post subject: |
|
|
Acolyte
Joined: 14 Aug 2006 Posts: 66 Location: Palo Alto, CA
|
This ORDER queue is present in 3 other clustered queue managers. PUT attribute is set to NO on all those queues as we have not started using those queue managers. Also, in the mainframe queue manager, ORDER queue is in the list of clustered queues and the attribute is showing up as NO in it. As a result, the application is not able to put the messages and it it is failing with the reason code as put inhibited.
No other application is using this queue. Initially, I created this queue as put inhibited, but I did change the put attribute later. |
|
Back to top |
|
 |
bruce2359 |
Posted: Fri Jul 05, 2013 7:18 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Not sure I understand your issue. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
senMQ |
Posted: Fri Jul 05, 2013 8:09 pm Post subject: |
|
|
Acolyte
Joined: 14 Aug 2006 Posts: 66 Location: Palo Alto, CA
|
I created a queue manager APP01 in a unix server and it has about 10 clustered queues. When I created the queues on this APP01 queue manager, all of them were put inhibited. But, later I switched to put enabled. There are other unix queue managers such as APP02 & APP03. There is a ORDER a queue in the APP01 queue manager and it is in the cluster. Right now, the queue has put enabled. I'm able to put messages in to the ORDER queue from APP02 & APP03. But, the application running on the mainframe server is not able to put the messages. It fails with the reason code put inihited. On the mainframe queue manager MQT, the clustered queue ORDER shows PUT as N. The mainframe application is able to put messages in to all the other unix queues and the PUT attribute shows up as Y.
Now, the issue is that MQT queue manager is not able to put messages in the ORDER queue on APP01. |
|
Back to top |
|
 |
fjb_saper |
Posted: Sat Jul 06, 2013 4:39 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
senMQ wrote: |
I created a queue manager APP01 in a unix server and it has about 10 clustered queues. When I created the queues on this APP01 queue manager, all of them were put inhibited. But, later I switched to put enabled. There are other unix queue managers such as APP02 & APP03. There is a ORDER a queue in the APP01 queue manager and it is in the cluster. Right now, the queue has put enabled. I'm able to put messages in to the ORDER queue from APP02 & APP03. But, the application running on the mainframe server is not able to put the messages. It fails with the reason code put inihited. On the mainframe queue manager MQT, the clustered queue ORDER shows PUT as N. The mainframe application is able to put messages in to all the other unix queues and the PUT attribute shows up as Y.
Now, the issue is that MQT queue manager is not able to put messages in the ORDER queue on APP01. |
Verify and if need be manually start the communications from the MF to it's FR and vice versa. Obviously the MF QMGR did not receive the update from the FR.  _________________ MQ & Broker admin |
|
Back to top |
|
 |
bruce2359 |
Posted: Sat Jul 06, 2013 4:45 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
I'm going to guess that you are new to MQ and MQ clusters. Further, I'm going to guess that you have not received any formal training. I'm going to guess that you are not using the WMQ Queue Manager Clusters manual as a reference.
I'm going to guess that you have been issuing lots of DELETE, DEFINE and ALTER commands hoping to change some attribute(s) that will fix this?
Other than posting here, what have you done to diagnose this? What MQ cluster commands have you used? What were the results?
Are all of these qmgrs in the exact same cluster? What is the name of the cluster? Are all of the queues in the exact same cluster? DISPLAY queue attributes, and post the results here.
Does the cluster have exactly two full repositories? And are the two full repositories fully interconnected? Is the mainframe qmgr a full repository?
Are the cluster channels to/from the mainframe qmgr in running state? _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
mqjeff |
Posted: Sat Jul 06, 2013 6:51 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
bruce2359 wrote: |
I'm going to guess that you are new to MQ and MQ clusters. Further, I'm going to guess that you have not received any formal training. |
No.
Assume all of that has been done.
Assume all reasonable measures have been taken. |
|
Back to top |
|
 |
bruce2359 |
Posted: Sat Jul 06, 2013 7:18 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
mqjeff wrote: |
bruce2359 wrote: |
I'm going to guess that you are new to MQ and MQ clusters. Further, I'm going to guess that you have not received any formal training. |
No.
Assume all of that has been done.
Assume all reasonable measures have been taken. |
No.
Effective PSI (Problem Source Identification) requires more than just presuming that, in this case, the m/f qmgr and queue are in a(ny) cluster, that they are the same cluster, that cluster sender/receiver channels are RUNNING, ...
I'm asking for confirmation that the basics have been addressed. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
senMQ |
Posted: Sat Jul 06, 2013 7:19 am Post subject: |
|
|
Acolyte
Joined: 14 Aug 2006 Posts: 66 Location: Palo Alto, CA
|
The cluster channels running between the unix and mainframe queue managers are running. The cluster channels connecting to the Full repositories are also running. Finally, the full repository has the correct information, i.e., I'm able to put the messages from the FR to this ORDER queue. Of course, all the objects belong to the same cluster. |
|
Back to top |
|
 |
bruce2359 |
Posted: Sat Jul 06, 2013 7:48 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
senMQ wrote: |
Now, the issue is that MQT queue manager is not able to put messages in the ORDER queue on APP01. |
So, briefly, you have one misbehaving application on one qmgr that gets a put(inhibited) R/C when attempting to put a message to one queue on one qmgr. What application? Are you using one of the IBM-supplied utilities?
Is the m/f a full-repository?
How do you know that it is the ORDER queue on APP01 qmgr that is causing the failure?
On the m/f, do these MQSC commands (or ISPF panel equivalents): DISPLAY QLOCAL(ORDER), DISPLAY CLUSQMGR(*) and DISPLAY QCLUSTER(*). Post the results here.
senMQ wrote: |
Finally, the full repository has the correct information, i.e., I'm able to put the messages from the FR to this ORDER queue. Of course, all the objects belong to the same cluster. |
What FR are you attempting to put messages to this ORDER queue? On the FR, do the same commands above. Post the results here. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
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
|
|
|
|