| Author |
Message
|
| subewma |
 Posted: Wed Apr 09, 2014 12:04 pm Post subject: mqrc 2059 |
 |
|
Newbie
Joined: 06 Jan 2012
Posts: 5
|
Hi,
We completed a MQ FP upgrade from 7.0.1.3 to 7.0.1.7 (AIX). There are multiple functional id's application uses to connect the queue manager. (server bindings mode).
Before MQ upgrade, application was able to connect queue manager using all functional id's .. After MQ FP upgrade, only one functional ID able to connect and all other functional ID's are throwing 2059 error.
9-Apr-2014 104147:QM:Connect:ERROR:Reason Code:2059:Q mgr not available
All ID's uses same C++ program code to connect MQ. The queue manager is a default queue manager and not passing any Queue manager name or host details in C++ program.
Tried the sample amqsput program with all id's and able to connect. This proves there is no possible issues with MQ, but i think issue may be somewhere at the env variable.. Tried MQ tracing, but no luck... Appreciate any thoughts to debug. |
|
| Back to top |
|
 |
| tczielke |
| Posted: Wed Apr 09, 2014 1:24 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA
|
Hi subewma,
What tracing options did you use?
I would use something like the following for this type of issue (where prgmname is your C++ executable):
strmqtrc -m qmgr -t all -p amqzlaa0,prgmname
If you are doing a typical server binding connection, your program will be connecting to the queue manager via a queue manager agent (i.e. amqzlaa0). I would want to review what the trace is saying is happening in the connection trace output on both my prgmname process and the relevant amqzlaa0 process to see if there are any clues. You can do a search for your pid number in the amqzlaa0 trace to help find where your pid is connecting into the queue manager agent process. |
|
| Back to top |
|
|
| interactivechannel |
| Posted: Thu Apr 10, 2014 2:56 am Post subject: |
|
|
Voyager
Joined: 20 May 2003
Posts: 94
Location: uk
|
| Any reason why you can't use the latest patch, 7.0.1.12? |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Apr 10, 2014 3:38 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
Choosing a 2 year old FP is strange.
_________________
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 |
|
|
| subewma |
| Posted: Thu Apr 10, 2014 2:39 pm Post subject: |
|
|
Newbie
Joined: 06 Jan 2012
Posts: 5
|
Thanks for your response..
@ tczielke, i used strmqtrc -m qmgr -t detail. When the application tried to connect with non working functional ID , the program PID is not even showing up in MQ trace. May be because it's getting terminated even before finding the queue manager... I went through amqzlaa0 trace files and can see thelogs about the id which is able to connect the queue manager. No trace logs regarding the other id's..
amqzlaa0 trace file when application tried to connect using non working Functional ID..
10:41:05.131914 6553676.38 : --------{ xtrTAisMatch
10:41:05.131920 6553676.38 : ---------{ xcsQueryProcessDetails
10:41:05.131952 6553676.38 : ---------} xcsQueryProcessDetails rc=OK
10:41:05.131957 6553676.38 : ---------{ xihGetQueueManagerNames
10:41:05.131961 6553676.38 : ---------} xihGetQueueManagerNames rc=OK
10:41:05.131966 6553676.38 : --------}! xtrTAisMatch rc=Unknown(1)
10:41:05.131970 6553676.38 : xihAllInitsCount was greater than zero
10:41:05.131974 6553676.38 : --------{ xcsReleaseThreadMutexSem
10:41:05.131978 6553676.38 : hmtx is 11000cc90
10:41:05.131982 6553676.38 : --------} xcsReleaseThreadMutexSem rc=OK
10:41:05.131985 6553676.38 : -------} xcsTerminate rc=OK
10:41:05.131989 6553676.38 : ------} hosTerminate rc=OK
10:41:05.131993 6553676.38 : -----} hlgTerminate rc=OK
10:41:05.131997 6553676.38 : -----{ xcsFreeQuickCell
10:41:05.132001 6553676.38 : hqc(2::11::11-4968)
10:41:05.132005 6553676.38 : -----} xcsFreeQuickCell rc=OK
10:41:05.132009 6553676.38 : ----} alsTermThread rc=OK
10:41:05.132013 6553676.38 : ---} almTerminate rc=OK
10:41:05.132017 6553676.38 : ---{ adhTerminate
10:41:05.132020 6553676.38 : ---} adhTerminate rc=OK
10:41:05.132025 6553676.38 : ---{ xcsFreeMemBlock
10:41:05.132029 6553676.38 : Freeing Block 2::10::10-2054312 of size 568. localAddress(7000000701f58a8)
amqzlaa0 trace file when application tried to connect using working Functional ID
10:36:40.798966 6553676.38 : -{ xtrTAisMatch
10:36:40.798971 6553676.38 : --{ xcsQueryProcessDetails
10:36:40.798983 6553676.38 : --} xcsQueryProcessDetails rc=OK
10:36:40.798987 6553676.38 : --{ xihGetQueueManagerNames
10:36:40.798991 6553676.38 : --} xihGetQueueManagerNames rc=OK
10:36:40.798995 6553676.38 : -}! xtrTAisMatch rc=Unknown(1)
10:36:40.798999 6553676.38 : -{ xcsGetEnvironmentString
10:36:40.799003 6553676.38 : xcsGetEnvironmentString[AMQ_SERVICE_MODULE] = NULL
10:36:40.799007 6553676.38 : -}! xcsGetEnvironmentString rc=xecE_E_ENV_VAR_NOT_FOUND
10:36:40.799011 6553676.38 : -{ xcsReleaseThreadMutexSem
10:36:40.799015 6553676.38 : hmtx is 11000cc90
10:36:40.799019 6553676.38 : -} xcsReleaseThreadMutexSem rc=OK
10:36:40.799023 6553676.38 : } xcsInitialize rc=OK
10:36:40.799027 6553676.38 : Calling thread function (1100015a0) with args(700000030005ea8)
10:36:40.799031 6553676.38 : { zlaMainThread
10:36:40.799043 6553676.38 : -{ xcsInitialize
10:36:40.799047 6553676.38 : --{ xcsRequestThreadMutexSem
10:36:40.799051 6553676.38 : hmtx is 11000cc90
10:36:40.799055 6553676.38 : --} xcsRequestThreadMutexSem rc=OK
10:36:40.799059 6553676.38 : --{ xcsStartPersistentTimerThread
10:36:40.799063 6553676.38 : --} xcsStartPersistentTimerThread rc=OK
10:36:40.799068 6553676.38 : --{ xcsConnectExistingSharedSubpool
10:36:40.799072 6553676.38 : Subpool = 2
10:36:40.799077 6553676.38 : ---{ xstGetSubpoolsLock
10:36:40.799081 6553676.38 : Subpool = 2
@ interactive channel and zpat... valid question, we are aiming for 7.0.1.12, but take some more time to reach there.. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Apr 10, 2014 3:01 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
| subewma wrote: |
| @ interactive channel and zpat... valid question, we are aiming for 7.0.1.12, but take some more time to reach there.. |
It takes just as much time to download and apply 7.0.1.12 as it does 7.0.1.7. And you end up with hundreds of more fixes, including all those present in 7.0.1.7.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| tczielke |
| Posted: Thu Apr 10, 2014 3:34 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA
|
I would recommend working a PMR with IBM, to further work the issue.
The records that stood out to me in the trace for the pid that did not work:
10:41:05.131966 6553676.38 : --------}! xtrTAisMatch rc=Unknown(1)
10:41:05.131970 6553676.38 : xihAllInitsCount was greater than zero
and the records that stood out to me in the trace for the pid that did work:
10:36:40.798995 6553676.38 : -}! xtrTAisMatch rc=Unknown(1)
10:36:40.798999 6553676.38 : -{ xcsGetEnvironmentString
are interesting, but I have no idea what that xihAllInitsCount is representing or meaning. Between the two records for each snippet above was 4 microseconds, which is probably the overhead to do the trace file write. So whatever is causing the queue manager agent to balk on starting this connection seems to be determined instantaneously.
Anyway, at this point I would open a PMR, if it was me. |
|
| Back to top |
|
|
| subewma |
| Posted: Wed Apr 16, 2014 2:29 pm Post subject: Resolved |
|
|
Newbie
Joined: 06 Jan 2012
Posts: 5
|
Found the issue... missing /usr/lib/ entry in LD_LIBRARY_PATH.
added the entry /usr/lib/ into LD_LIBRARY_PATH and 2059 error disappeared. application able to connect successfully.
Thanks everyone for your time and valuable suggestions.. |
|
| Back to top |
|
|
|
|
