| Author |
Message
|
| lotusphilo |
 Posted: Tue Apr 20, 2004 5:07 am Post subject: 2018 |
 |
|
Voyager
Joined: 31 Mar 2004
Posts: 76
|
One of our developers is getting a 2018. We're running 5.3 on W2K Server.
I know that means the hconn is not valid but I dont understand why. The application is already listening to the queue, checking for messages.
Why would the connection handle be invalidated? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Apr 20, 2004 5:21 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
He's trying to use it from within a different thread when it's not a shareable handle.
He's trying to use it in a different scope than it's defined in.
...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| lotusphilo |
| Posted: Tue Apr 20, 2004 6:29 am Post subject: |
|
|
Voyager
Joined: 31 Mar 2004
Posts: 76
|
Nevermind, I understand.
thanks |
|
| Back to top |
|
|
| lotusphilo |
| Posted: Tue Apr 20, 2004 6:33 am Post subject: |
|
|
Voyager
Joined: 31 Mar 2004
Posts: 76
|
Just to be clear. Because the application is multithreading the handle is becoming invalid because it is not a sharable handle across multiple threads?
Is there a way to make the handle shareable in this situation? |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Tue Apr 20, 2004 9:30 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| My understanding is that each thread (or TCB in z/OS) has to have it's own connection handle fi it is going to do MQ API calls, however it is possible (certainly on z/OS) to have one task that does all of the MQ related work under one Hconn....at least that is the way I got around it on z/OS. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Apr 20, 2004 9:42 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| lotusphilo wrote: |
| Just to be clear. Because the application is multithreading the handle is becoming invalid because it is not a sharable handle across multiple threads? |
Yes.
| Quote: |
| Is there a way to make the handle shareable in this situation? |
Yes, at least with 5.3. You can specify an MQCNO option to the MQCONNX call that will allow you to share the HConn that's returned.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| lotusphilo |
| Posted: Fri Apr 30, 2004 6:05 am Post subject: |
|
|
Voyager
Joined: 31 Mar 2004
Posts: 76
|
| What steps do I need to take to make this change? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Apr 30, 2004 6:09 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| lotusphilo wrote: |
| What steps do I need to take to make this change? |
You need to change the code to use MQCONNX, and specify the "shareable handle" option in the MQCNO parameter.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| lotusphilo |
| Posted: Fri Apr 30, 2004 6:26 am Post subject: |
|
|
Voyager
Joined: 31 Mar 2004
Posts: 76
|
Jeff,
Thanks for your help.
Oh, there is one other thing. Their listener is still able to pull messages off of the queue but it is throwing the 2018 every 3rd or 4th message.
Why would WMQ allow the listener to continue to pull messages off the queue with an invalid handle? |
|
| Back to top |
|
|
| lotusphilo |
| Posted: Fri Apr 30, 2004 6:44 am Post subject: |
|
|
Voyager
Joined: 31 Mar 2004
Posts: 76
|
I forgot to mention that the developers are on the .Net framework.
In their code, they are using a MQ CONNECTION MANAGER. That HCONN/MQCONN is black box to them.
Does this impact the approach to resolving this issue? |
|
| Back to top |
|
|
| JasonE |
| Posted: Tue May 04, 2004 1:15 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
By default, .NET makes the hconn share_block, ie it is by default sharable across processes, UNLESS the application is running in an MTS/COM+ environment, in which case it does not set the option because the MQ MTS/COM+ layer would give you that anyway.
I would step back a bit - 2018 means invalid hconn, and although I think the suggestion of cross thread is a good one, I dont think its the issue here.
Are you sure the app is not calling the MQQueueManager.disconnect method, then trying to do something like MQQueueManager.accessqueue?
Note this update assumes you are coding with the MQ supported .NET interface as shipped with WMQ 5.3 fixpack 5, not the earlier support pack versions. |
|
| Back to top |
|
|
|
|
