ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » MQ connection issue

Post new topic  Reply to topic
 MQ connection issue « View previous topic :: View next topic » 
Author Message
MQMITH
PostPosted: Thu Sep 04, 2014 10:04 pm    Post subject: MQ connection issue Reply with quote

Novice

Joined: 22 May 2014
Posts: 10

Hi .. need a help in a mq connection issue. client connecting to a QMGR using some script which uses jms backend and I can see the channel status is RUNNING state after his connection.

- After the successful connection he is trying to PUT a message and he is getting 2018 MQRC_HCONN_ERROR error.
- he says the same script is working fine for other QMGR.
- I see the SVRCONN as in running state with SUBSTATE(MQGET), is that mean is he using open option GET instead of PUT ?
- But user saying, he just connecting to mq using the connection parameters nothing other than that.

Any one faced same issue before and

what that mean if a SVRCONN shows SUBSTATE(MQGET) , normally I see SUBSTATE(RECEIVE) for other channels..

Thanks in advance.
Back to top
View user's profile Send private message
MQsysprog
PostPosted: Thu Sep 04, 2014 10:22 pm    Post subject: Reply with quote

Centurion

Joined: 24 Feb 2014
Posts: 116

Hello,

The 2018 Reason code comes from an invalid connection handle used by the application ,so probably you should investigate if the mqconn really works well or the handle is not used in the right way.
The state SUBSTATE(MQGET) means that the channel is active and waiting for traffic,or in other words for messages to get from its xmitq and send to the remote receiver channel .
Back to top
View user's profile Send private message
MQMITH
PostPosted: Thu Sep 04, 2014 10:54 pm    Post subject: Reply with quote

Novice

Joined: 22 May 2014
Posts: 10

Thanks for the reply MQsysprog.

###########
The state SUBSTATE(MQGET) means that the channel is active and waiting for traffic,or in other words for messages to get from its xmitq and send to the remote receiver channel .
###########

I can understand if SUBSTATE(MQGET) is showing for a SDR channel. But here its showing for a SVRCONN channel. So is that mean the SVRCONN connected to a QMGR for GET messages from a QL?

And I tried on the client mechine using the sample put and get to QMGR, it worked fine. so again....

- After the successful connection he is trying to PUT a message and he is getting 2018 MQRC_HCONN_ERROR error.
- he says the same script is working fine for other QMGR.
- Is there any possibility like.. He opened his connection for GET and he is PUTing the message??

Thanks
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Thu Sep 04, 2014 11:36 pm    Post subject: Reply with quote

Grand Master

Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand

It sounds more likely to me that the channels is not a SHARECNV channel and that the application is actually sat in an MQGET.

Of course an MQ Trace will show exactly what the application is doing. Or indeed you could glean it from Activity Trace. The one thing I have learned though in my 30 years of debugging user problems is that when they say "the same X is working fine for other X" or "this has always worked before" they are quite often being economical with the truth and you find out that it's not exactly the same environment or they have just added in this extra 2,000 lines of code etc. etc.

Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
MQMITH
PostPosted: Fri Sep 05, 2014 12:34 am    Post subject: Reply with quote

Novice

Joined: 22 May 2014
Posts: 10

Thanks Paul.. Well Said "the same X is working fine for other X" .

I see SVRCONN SHARECNV value as 10, anyway I'll ask them to arrange one more round of testing and will try to enable the MQ tracing from our end.

mean while appreciate if any one suggest the other posibilities of the issue..

Thank you.. Mith
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Fri Sep 05, 2014 12:49 am    Post subject: Reply with quote

Grand Master

Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand

The SHARECNV value is only half the story so doesn't tell you what the channel is actually running with. Look at the MAXSHCNV value in the channel status. The Java client 'could' have disabled sharing or whatever.

Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
tczielke
PostPosted: Fri Sep 05, 2014 5:38 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA

MQMITH wrote:
I'll ask them to arrange one more round of testing and will try to enable the MQ tracing from our end.


In case you will be using strmqtrc for your queue manager tracing, here are a few tips in using tracing, in case you were not aware.

1. You will more than likely need to trace the amqrmppa channel pooling process, if your SVRCONN channel runs on that process. Here is a good way to limit the tracing to just an API trace on that process. Look for your channel name in the trace to identify what thread (or threads) you are running on.

strmqtrc -m qmgr -t api -p amqrmppa

2. Tracing an MQI channel will have some differences than tracing an application locally connected to the queue manager. For example, a standard MQGET from the client app usually gets converted to a callback construct on the MQI SVRCONN channel, which will run on more than one thread on the amqrmppa process. So your client apps work will be multi-threaded on the amqrmppa process, even if your client app is single threaded.

3. MH06 Trace Tools supportpac can be very helpful in reading strmqtrc traces. I am not sure what platform your queue manager runs on, but the mqtrcfrmt tool in this supportpac supports Linux x86, Solaris SPARC, and Windows. If Windows, please note that mqtrcfrmt does correctly read a 32 bit application trace, but not a 64 bit trace (a fix is underway for this). For investigating a 2018 error, you can use the user customizeable API summary trace feature to create a few line summary of each API call and track the Hconns as they flow threw the app. This would be very helpful in potentially identifying the issue.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » MQ connection issue
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.