| Author |
Message
|
| vmcgloin |
 Posted: Tue Sep 07, 2010 7:18 am Post subject: dotnet MQRC_OPTIONS_ERROR |
 |
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
Hi,
I am currently supporting the server side of an client application connecting to MQv6 using .Net (from a v7 client but not using WCF).
The application succeeds in putting a request message but fails with MQRC_OPTION_ERROR when getting the reply. I would love to be able to see what the options in use are, but the dotnet app generates proxy classes and I have no visibility of the code (nor would I understand it). As far as the developer is concerned we are only using defaults so it should work...
Can anyone provide any pointers to how to see what the options used are or what approach should be taken to investigate please?
Here are the extracts in the trace file which stand out as relevant: -
I’m hoping that it will make more sense to someone here than it does to me.
| Code: |
--} MQWebRequest::GetResponse (rc=OK)
00007A52 13:15:48.250948 4772.1 : --{ MQWebResponse::regetContextMessage
00007A53 13:15:48.253546 4772.1 : ---{ MQWebResponse::regetContextMessage
00007A54 13:15:48.253942 4772.1 : Constructing IBM.WMQ.MQMessageDescriptor#03B6C0A6 lib/dotnet/pc/winnt/nmqi/MQMessageDescriptor.cs p000-L090730 1.2 09/06/04 13:37:16
00007A55 13:15:48.253978 4772.1 : ----{ MQMessageDescriptor.ClearInvalidFields(MQLONG)
00007A56 13:15:48.254011 4772.1 : ----} MQMessageDescriptor.ClearInvalidFields(MQLONG) (rc=OK)
00007A57 13:15:48.254162 4772.1 : Constructing IBM.WMQSOAP.RFH2Message#01FADFF0 lib/dotnet/pc/winnt/baseclasses/MQMessage.cs p000-L090730 1.1 09/06/03 05:52:32
00007A58 13:15:48.254193 4772.1 : ----{ MQMessage.ClearMessage()
00007A59 13:15:48.254225 4772.1 : ----} MQMessage.ClearMessage() (rc=OK)
00007A5A 13:15:48.254281 4772.1 : Constructing IBM.WMQ.MQMessageDescriptor#0104DD1B lib/dotnet/pc/winnt/nmqi/MQMessageDescriptor.cs p000-L090730 1.2 09/06/04 13:37:16
00007A5B 13:15:48.254309 4772.1 : ----{ MQMessageDescriptor.ClearInvalidFields(MQLONG)
00007A5C 13:15:48.254339 4772.1 : ----} MQMessageDescriptor.ClearInvalidFields(MQLONG) (rc=OK)
00007A5D 13:15:48.254365 4772.1 : ----{ RFH2Message::setFixed
00007A5E 13:15:48.254391 4772.1 : ----} RFH2Message::setFixed (rc=OK)
00007A5F 13:15:48.254745 4772.1 : Constructing IBM.WMQ.MQGetMessageOptions#01EE524B lib/dotnet/pc/winnt/nmqi/MQGetMessageOptions.cs p000-L090730 1.2 09/06/04 13:37:10
00007A60 13:15:48.255702 4772.1 : ----{ MQGetMessageOptions.ClearInvalidFields(MQLONG)
00007A61 13:15:48.258188 4772.1 : ----} MQGetMessageOptions.ClearInvalidFields(MQLONG) (rc=OK)
00007A62 13:15:48.260287 4772.1 : ----{ MQDestination.Get(MQMessage,MQGetMessageOptions)
00007A63 13:15:48.265033 4772.1 : -----{ MQDestination.Get(MQMessage,MQGetMessageOptions,int)
00007A64 13:15:48.265070 4772.1 : ------{ MQManagedObject.QueryAttribute(MQLONG)
00007A65 13:15:48.265175 4772.1 : Attribute Type: 31
00007A66 13:15:48.265205 4772.1 : -------{ MQManagedObject.Inquire(MQLONG [ ],MQLONG [ ],MQBYTE [ ])
00007A67 13:15:48.265233 4772.1 : --------{ UnmanagedNmqiMQ.MQINQ(Hconn,Hobj,MQLONG,MQLONG [ ],MQLONG,MQLONG [ ],MQLONG,MQCHAR [ ],out int,out int)
00007A68 13:15:48.265259 4772.1 : ---------{ UnmanagedNmqiMQ.GetUnmanagedHconn(Hconn)
00007A69 13:15:48.265286 4772.1 : ---------} UnmanagedNmqiMQ.GetUnmanagedHconn(Hconn) (rc=OK)
00007A6A 13:15:48.265311 4772.1 : ---------{ UnmanagedNmqiMQ.GetLocalHobj(Hobj)
00007A6B 13:15:48.265337 4772.1 : ---------} UnmanagedNmqiMQ.GetLocalHobj(Hobj) (rc=OK)
00007A6C 13:15:48.265363 4772.1 : ---------{ MQINQ
00007B63 13:15:48.359583 4772.1 RSESS:000001 !! - MQI:MQGET HConn=00000005 HObj=00000067 DataLen=FFFFFFFF rc=000007FE
00007B64 13:15:48.359609 4772.1 RSESS:000001 ---------{ reqReleaseConn
00007B65 13:15:48.359635 4772.1 RSESS:000001 ----------{ xcsQueryThreadMutexSem
00007B66 13:15:48.359664 4772.1 RSESS:000001 hmtx is 003ED5D8
00007B67 13:15:48.359691 4772.1 RSESS:000001 ----------}! xcsQueryThreadMutexSem (rc=Unknown(1))
00007B68 13:15:48.359727 4772.1 RSESS:000001 ----------{ xcsReleaseThreadMutexSem
00007B69 13:15:48.359754 4772.1 RSESS:000001 ----------} xcsReleaseThreadMutexSem (rc=OK)
00007B6A 13:15:48.359787 4772.1 RSESS:000001 ----------{ rriLookupRelease
00007B6B 13:15:48.359883 4772.1 RSESS:000001 -----------{ xcsRequestThreadMutexSem
00007B6C 13:15:48.359913 4772.1 RSESS:000001 -----------} xcsRequestThreadMutexSem (rc=OK)
00007B6D 13:15:48.359939 4772.1 RSESS:000001 -----------{ xcsReleaseThreadMutexSem
00007B6E 13:15:48.359965 4772.1 RSESS:000001 -----------} xcsReleaseThreadMutexSem (rc=OK)
00007B6F 13:15:48.359990 4772.1 RSESS:000001 ----------} rriLookupRelease (rc=OK)
00007B70 13:15:48.360015 4772.1 RSESS:000001 ---------} reqReleaseConn (rc=OK)
00007B71 13:15:48.360041 4772.1 RSESS:000001 --------}! MQGET (rc=MQRC_OPTIONS_ERROR)
00007B72 13:15:48.360075 4772.1 : -------}! MQGET (rc=MQRC_OPTIONS_ERROR)
00007B73 13:15:48.360345 4772.1 : ------} UnmanagedNmqiMQ.MQGET(Hconn,Hobj,MQMessageDescriptor,MQGetMessageOptions,MQLONG,MQBYTE [ ],out int,out int,out int) (rc=OK)
00007B74 13:15:48.361096 4772.1 : MQException CompCode: 2 Reason: 2046
00007B75 13:15:48.368325 4772.1 : -----}! MQDestination.Get(MQMessage,MQGetMessageOptions,int) (rc=MQRC_OPTIONS_ERROR)
00007B76 13:15:48.368374 4772.1 : ----}! MQDestination.Get(MQMessage,MQGetMessageOptions) (rc=MQRC_OPTIONS_ERROR)
00007B77 13:15:48.368815 4772.1 : ---}! MQWebResponse::regetContextMessage (rc=MQRC_OPTIONS_ERROR)
00007B78 13:15:48.370051 4772.1 : 0
00007B79 13:15:48.370090 4772.1 : 0
00007B7A 13:15:48.373154 4772.1 : ---{ xcsGetMessageParts
00007B7B 13:15:48.373200 4772.1 : msgid:20009939 ccsid:000004B0 bb:013CB01C bbl:00000400 eb:013CB428 ebl:00000000 rb:013CB434 rbl:00000000 control:00000007 |
Thanks,
Vicky |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Sep 07, 2010 7:34 am Post subject: Re: dotnet MQRC_OPTIONS_ERROR |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| vmcgloin wrote: |
| The application succeeds in putting a request message but fails with MQRC_OPTION_ERROR when getting the reply. |
Obvious questions:
- Did this ever work? If it did, what changed?
- Does it work in one environment and not the other? If so, is it trying to get the reply from a remote queue in the failing environment?
- Can the developer be beaten with a trout until he provides the options for the benefit of those that understand them?
- How does the developer know that the defaults should work?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vmcgloin |
| Posted: Tue Sep 07, 2010 7:55 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
I have had my trout handy lots... and the obvious questions are what I need right now - thanks!
It has only worked with a server connection to the developers local qmgr.
What does not work is a client connection e.g.
The URI used successfully with the developers local MQ server install (MQ v7.0.1) is:
| Code: |
| Me.Url="jms:/queue?destination=SOAPN.demos@WMQSOAP.DEMO.QM&connectionFactory=(connectQueueManager(WMQSOAP.DEMO.QM))&initialContextFactory=com.ibm.mq.jms.Nojndi&targetService=MQTest.asmx&replyDestination=SYSTEM.SOAP.RESPONSE.QUEUE" |
The URI tried with the dev integration server (MQ 6.0.2.2) is similar to this:
| Code: |
| Me.Url = "jms:/queue?destination=ESB_RQ_TOP_CATPRODAVAIL@QD02TOPQM1&connectionFactory=(connectQueueManager(QD02TOPQM1)clientChannel(SYSTEM.ADMIN.SVRCONN)clientConnection(nn.n.n.nnn(nnnnn)))&initialContextFactory=com.ibm.mq.jms.Nojndi&targetService=CatalogProductAvailabilityPort.asmx&replyDestination=TOP01.0000.WMQ01" |
The developer does not know what the options used are as they are being generated from the above URI within their .Net development framework
We do not know that the default should work. This is the first test. We also do not know how to change the defaults (and I am happy to take a trout for it since I'm just helping out and do not have a clue, and I will happily pass on the beating).
Thanks,
Vicky |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Sep 07, 2010 8:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| vmcgloin wrote: |
| We do not know that the default should work. This is the first test. We also do not know how to change the defaults (and I am happy to take a trout for it since I'm just helping out and do not have a clue, and I will happily pass on the beating) |
Another quality development from the application team that brought you STRAP & CHORDIANT.
The next obvious question (until a qualified .NET developer comes along) is what the difference between SYSTEM.SOAP.RESPONSE.QUEUE on his WMQSOAP.DEMO.QM and TOP01.0000.WMQ01 on QD02TOPQM1? If (as I suspect) TOP01.0000.WMQ01 is the queue that links his application to the WMB broker, could it be a remote queue down which the message flows from his application (on a separate server) to the broker machine (QD02WMBQM1??)? If so, opening that queue to read the reply back is not going to go well. Shouldn't the reply queue be WMQ01.0000.TOP01?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Sep 07, 2010 8:19 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Nobody should be using SYSTEM.ADMIN.SVRCONN. That will fail you in a security audit on day 0.
Also, the trace file originally shown should potentially actually list the MQOO structure in use. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Sep 07, 2010 8:38 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| Nobody should be using SYSTEM.ADMIN.SVRCONN. That will fail you in a security audit on day 0. |
But that's not likely to be the source of the posted problem.
It's also something likely to be fixed once the testing has progressed a little (i.e. actually working on a dev server rather than some guy's laptop).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vmcgloin |
| Posted: Tue Sep 07, 2010 9:49 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
 The svrconn channel is one of the issues I have said will be sorted as soon as the app is working.
The reply queue is fine - it is a local queue on the same queue manager that the request was sent to successfully.
I am looking at the full trace file now (only just got possession of it).
As always I appreciate your help guys and though I would love to comment on 'quality' I won't... 
Thanks,
Vicky |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Sep 07, 2010 12:12 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| As always I appreciate your help guys and though I would love to comment on 'quality' I won't... |
Quality of what??
_________________
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 |
|
|
| fjb_saper |
| Posted: Tue Sep 07, 2010 1:36 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| vmcgloin wrote: |
| The reply queue is fine - it is a local queue on the same queue manager that the request was sent to successfully. |
This response is not really meaningful.
The right response would be:
The reply queue is a local queue on the queue manager the requester is connected to.
Imagine the scenario where the qmgr the requester connects to does not process the message. The queue manager the request was sent to successfully is not accessed by the requester. As such it will never be able to consume the reply...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| shashikanth_in |
| Posted: Wed Sep 08, 2010 12:43 am Post subject: |
|
|
Centurion
Joined: 26 Feb 2009
Posts: 123
|
One possibility is that the application is using an MQGET option which is new in MQ v7.0.1 and is not available in MQ v6.0. As you have seen the application works when connecting to MQ v7 but fails with v6.
Developer will have to check what options are being passed to MQGET. |
|
| Back to top |
|
|
| vmcgloin |
| Posted: Wed Sep 08, 2010 1:24 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
| fjb_saper wrote: |
The reply queue is a local queue on the queue manager the requester is connected to. |
That is what I meant to say 
I was referring to a comment Vitor made earlier about other systems at the company I work for.
I assume from the response so far that I am not missing a fundamental incompatibility between the .Net MQ libraries in a V7.0.1 client and a v6.0.2.2 qmgr?
| Quote: |
| Developer will have to check what options are being passed to MQGET. |
My problem is that the developer does not know what options are being used. All the MQ interface code is generated automatically by the .Net framework they are using and I do not know (or want to know) how to get it out of the dll's...
And I cannot quite work out how to see the getMessageOptions from the trace...
| Code: |
00007B59 13:15:48.359292 4772.1 RSESS:000001 !! - Getmsgopts:
00007B5A 13:15:48.359317 4772.1 RSESS:000001 Data:-
00007B5A 13:15:48.359317 4772.1 RSESS:000001 0x0392E1A0 47 4D 4F 20 02 00 00 00 01 20 00 02 10 27 00 00 : GMO ..... ...'..
00007B5A 13:15:48.359317 4772.1 RSESS:000001 0x0392E1B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
00007B5A 13:15:48.359317 4772.1 RSESS:000001 2 lines suppressed, same as above
00007B5A 13:15:48.359317 4772.1 RSESS:000001 0x0392E1E0 00 00 00 00 00 00 00 00 02 00 00 00 20 20 20 20 : ............
00007B5A 13:15:48.359317 4772.1 RSESS:000001 0x0392E1F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
00007B5A 13:15:48.359317 4772.1 RSESS:000001 0x0392E200 FF FF FF FF 00 00 00 00 06 00 00 00 88 E1 92 03 : ÿÿÿÿ........ˆá’. |
I think we will to raise a PMR now to get some more help... |
|
| Back to top |
|
|
| shashikanth_in |
| Posted: Wed Sep 08, 2010 2:26 am Post subject: |
|
|
Centurion
Joined: 26 Feb 2009
Posts: 123
|
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 08, 2010 4:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| vmcgloin wrote: |
| I was referring to a comment Vitor made earlier about other systems at the company I work for. |
Potentially harsh of me & I apologise. 
Of course, any implied weakness in the development does not in any way extend to the fine work done by the middleware team...
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| nathanw |
| Posted: Wed Sep 08, 2010 4:59 am Post subject: |
|
|
Knight
Joined: 14 Jul 2004
Posts: 550
|
| Vitor wrote: |
| vmcgloin wrote: |
| I was referring to a comment Vitor made earlier about other systems at the company I work for. |
Potentially harsh of me & I apologise.
Of course, any implied weakness in the development does not in any way extend to the fine work done by the middleware team... |
nice save!
_________________
Who is General Failure and why is he reading my hard drive?
Artificial Intelligence stands no chance against Natural Stupidity.
Only the User Trace Speaks The Truth  |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 08, 2010 5:20 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| nathanw wrote: |
| Vitor wrote: |
| vmcgloin wrote: |
| I was referring to a comment Vitor made earlier about other systems at the company I work for. |
Potentially harsh of me & I apologise.
Of course, any implied weakness in the development does not in any way extend to the fine work done by the middleware team... |
nice save! |
Hey, they know where I live.... 
Besides, the team always had a soft spot for me. It was at the back of the car park at New Logic, they used to throw me in & see how long it took me to sink up to my neck. If the STRAP testing was going well they used to pull me out again. Mostly.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
