| Author |
Message
|
| aravindks3 |
 Posted: Sun Oct 08, 2017 11:52 pm Post subject: MQOO_INPUT_AS_Q_DEF for MQOPEN with CCDT |
 |
|
Novice
Joined: 18 Jun 2017
Posts: 15
|
I am using CCDT file for my application to do MQ connectivity.
My CCDT file has 2 Nodes specified. My Adapter was earlier referring to Queue manager running on the same server, so for MQOPEN options --> MQOO_INPUT_AS_Q_DEF was used.
But now Instead of Local queue manager, we are using CCDT file for connectivity. There is no change in application code, except that the code is compiled through mqic library instead of mqm library and also setup environment variables for referring CCDT file.
Now i am facing problem that i cannot read message from the queue if both the nodes specified in CCDT are UP and running.
If we bring down one node down, then i can read the messages available in the QUEUE.
I doubt is it because of MQOPEN options defined earlier for local Queue manager is causing this.
Earlier options we are using are as follows for GET adapter
MQOO_OUTPUT + MQOO_FAIL_IF_QUIESCING[/b]
Please help me on this. |
|
| Back to top |
|
 |
| zpat |
| Posted: Mon Oct 09, 2017 12:16 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
What MQRC do you get?
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Oct 09, 2017 1:47 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Is there any leftover code from before the CCDT? Remember that the MQEnvironment is a singleton... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Oct 09, 2017 2:42 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Take a look at THIS.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| aravindks3 |
| Posted: Mon Oct 09, 2017 6:49 pm Post subject: |
|
|
Novice
Joined: 18 Jun 2017
Posts: 15
|
| zpat wrote: |
| What MQRC do you get? |
I am not sure, i checked the application code and when i try MQGET, if MQRC_NO_MSG_AVAILABLE, the code is not printing anything, in else part we are checking if MQCC_FAILED and trying to get new connection.
But i am not going to else part. So i guess it is going to if condition and not printing anything as per code. |
|
| Back to top |
|
|
| aravindks3 |
| Posted: Mon Oct 09, 2017 6:52 pm Post subject: |
|
|
Novice
Joined: 18 Jun 2017
Posts: 15
|
| fjb_saper wrote: |
| Is there any leftover code from before the CCDT? Remember that the MQEnvironment is a singleton... |
No. Because when they bring down one node, the application reads the response from the queue and works normally. But only when the 2 nodes are up, the application is not able to read any message from the queue.
For CCDT connectivity can i use MQOO_INPUT_AS_Q_DEF for MQOPEN or not? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Oct 09, 2017 8:14 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| aravindks3 wrote: |
| fjb_saper wrote: |
| Is there any leftover code from before the CCDT? Remember that the MQEnvironment is a singleton... |
No. Because when they bring down one node, the application reads the response from the queue and works normally. But only when the 2 nodes are up, the application is not able to read any message from the queue.
For CCDT connectivity can i use MQOO_INPUT_AS_Q_DEF for MQOPEN or not? |
The MQOO setting has nothing to do with the CCDT. However what could be happening is that you are trying to open queue A on QM1 when connected to QM2 and queue A on QM2 on your connection with QM1...
Remember that you can only read from a queue that is local to a queue manager you are connected to.
I suggest you remove any indication to a qmgr from the MQOPEN. Let the connection handle it.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| aravindks3 |
| Posted: Tue Oct 10, 2017 12:45 am Post subject: |
|
|
Novice
Joined: 18 Jun 2017
Posts: 15
|
| fjb_saper wrote: |
| aravindks3 wrote: |
| fjb_saper wrote: |
| Is there any leftover code from before the CCDT? Remember that the MQEnvironment is a singleton... |
No. Because when they bring down one node, the application reads the response from the queue and works normally. But only when the 2 nodes are up, the application is not able to read any message from the queue.
For CCDT connectivity can i use MQOO_INPUT_AS_Q_DEF for MQOPEN or not? |
The MQOO setting has nothing to do with the CCDT. However what could be happening is that you are trying to open queue A on QM1 when connected to QM2 and queue A on QM2 on your connection with QM1...
Remember that you can only read from a queue that is local to a queue manager you are connected to.
I suggest you remove any indication to a qmgr from the MQOPEN. Let the connection handle it.
Have fun |
I Just call the default MQOPEN method as follows and pass the options as specified before.
MQOPEN(Hcon, /* connection handle */
&od, /* object descriptor for queue */
O_options, /* open options */
&Hobj, /* object handle */
&OpenCode, /* completion code */
&Reason); /* reason code */
Other than this i dont specify the Queue manager for MQOPEn.
I specify the Queue manager for MQCONN only. And the Queue manager name is same for both nodes available in CCDT file. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Oct 10, 2017 12:51 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| aravindks3 wrote: |
| ...And the Queue manager name is same for both nodes available in CCDT file. |
So you're using an alias name?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Oct 10, 2017 1:35 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You must print the reason code for the MQRC > 0. It will be in the linked exception.
This is vital - no point in doing anything else until you know why MQ is rejecting your MQI call.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| aravindks3 |
| Posted: Tue Oct 10, 2017 6:36 pm Post subject: |
|
|
Novice
Joined: 18 Jun 2017
Posts: 15
|
| exerk wrote: |
| Take a look at THIS. |
The article was really helpful and thanks for this. But i already use wildcard for MQCONN as *<QueueManager> name.
Still my MQ admin says my application is connecting to 2 nodes instead of connecting to one node. I dont understand that.
Because if i get one connection object on MQCONN call, i wont look for another connection object rite? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Oct 10, 2017 8:29 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| aravindks3 wrote: |
I Just call the default MQOPEN method as follows and pass the options as specified before.
| Code: |
MQOPEN(Hcon, /* connection handle */
&od, /* object descriptor for queue */
O_options, /* open options */
&Hobj, /* object handle */
&OpenCode, /* completion code */
&Reason); /* reason code */ |
Other than this i dont specify the Queue manager for MQOPEn.
I specify the Queue manager for MQCONN only. And the Queue manager name is same for both nodes available in CCDT file. |
The question here is what are the exact values passed on the object descriptor for the queue, and what is the reason code being returned...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Oct 11, 2017 1:26 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Well, if one node is blocking the other node, then don't really on the 'default' value defined for the queue. Obviously, somewhere the attribute DEFSOPT is set to "EXCL" (or attribute "NOSHARE" is on). Just explicitly set it in your code.
i.e.
| Code: |
O_options = MQOO_INPUT_SHARED | MQOO_FAIL_IF_QUIESCING;
MQOPEN(Hcon, &od, O_options, &Hobj, &OpenCode, &Reason); |
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
|
|
