| Author |
Message
|
| bdrummond |
 Posted: Wed Sep 26, 2007 1:07 am Post subject: |
 |
|
Disciple
Joined: 06 May 2004
Posts: 164
|
Sorry, I don't think I mentioned it but I'm not using root.
I am using a user that is in the mqm group so there shouldn't be any problems with authority.
When trying to connect the toolkit (or MQ Explorer for that matter I've noticed today), I am recieving 2195 errors (UNEXPECTED_ERROR) and in the error log of the ConfigMgr QM, I am receiving the errors that I pointed out in my earlier posts (AMQ9503 and AMQ9492).
When running the amqscnxc program from my windows machine, this seems to work without any problems. (Full MQ install)
This issue seems to get more puzzling as time goes by.  |
|
| Back to top |
|
 |
| bdrummond |
| Posted: Wed Sep 26, 2007 1:42 am Post subject: |
|
|
Disciple
Joined: 06 May 2004
Posts: 164
|
Looks as though the ConfigMgr QM is corrupt in some way.
I have created a new QM and ConfigMgr on the same box (different port)and can connect without any problems.
When I create a new SVRCONN channel on the failing ConfigMgr QM and start it up on a different port, we get the same errors.
Very strange. Not sure if anyone has made any changes or not but it appears that the Qmgr is not a happy bunny.
I will try and recreate the QM and see if this resolves the problem. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Sep 26, 2007 2:59 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20768
Location: LI,NY
|
| bdrummond wrote: |
Sorry, I don't think I mentioned it but I'm not using root.
I am using a user that is in the mqm group so there shouldn't be any problems with authority. |
This is so not true:
| bdrummond wrote: |
06/10/06 08:26:17 - Process(10028.7) User(root) Program(amqrmppa)
AMQ9503: Channel negotiation failed. |
Because if it were true you would have something like
| Quote: |
| 06/10/06 08:26:17 - Process(10028.7) User(mqm) Program(amqrmppa) |
Either your channel process or Listener is running under root.
You might as well check the executable file permissions and sticky bit...
Now please check with
| Code: |
| ps -ef | grep "10028.7" |
and you should be able to confirm.
Does root have any authorizations to the qmgr? Either as part of the mqm group or specified through setmqaut...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bdrummond |
| Posted: Wed Sep 26, 2007 3:28 am Post subject: |
|
|
Disciple
Joined: 06 May 2004
Posts: 164
|
| fjb_saper wrote: |
| bdrummond wrote: |
Sorry, I don't think I mentioned it but I'm not using root.
I am using a user that is in the mqm group so there shouldn't be any problems with authority. |
This is so not true:
| bdrummond wrote: |
06/10/06 08:26:17 - Process(10028.7) User(root) Program(amqrmppa)
AMQ9503: Channel negotiation failed. |
Because if it were true you would have something like
| Quote: |
| 06/10/06 08:26:17 - Process(10028.7) User(mqm) Program(amqrmppa) |
|
I had 'quoted' someone else's error message but failed to change 'root' to the user I am running the process under. I can assure you that I am not running any processes under 'root'
| fjb_saper wrote: |
Either your channel process or Listener is running under root.
You might as well check the executable file permissions and sticky bit...
Now please check with
| Code: |
| ps -ef | grep "10028.7" |
and you should be able to confirm.
Does root have any authorizations to the qmgr? Either as part of the mqm group or specified through setmqaut...
Enjoy |
When running the 'ps -ef' command for the process that is failing, this is owned and being run by a user in the mqm group. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Sep 26, 2007 3:31 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20768
Location: LI,NY
|
Has the qmgr had a refresh security since the user was added to the mqm group or a restart ? and please a new thread would have avoided the confusion...
Are all the correct ACLs created ?
What is in the mcauser of the SYSTEM.BROKER.SVRCONN of the configmgr's qmgr?
Any FDC files being cut?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bdrummond |
| Posted: Wed Sep 26, 2007 4:02 am Post subject: |
|
|
Disciple
Joined: 06 May 2004
Posts: 164
|
Yes, maybe I should have started a new thread in hindsight. I just used the search function and found a thread that had similar errors to what I was experiencing. Sorry.
ACL entries are all set up.
FDC files being generated in /var/mqm/errors but not at the same time that the listener is restarted or the toolkit connecting.
The FDC being generated is as follows:
+-----------------------------------------------------------------------------+
| |
| WebSphere MQ First Failure Symptom Report |
| ========================================= |
| |
| Date/Time :- Wednesday September 26 12:13:48 BST 2007 |
| Host Name :- hutpmb01 (AIX 5.3) |
| PIDS :- 5724H7201 |
| LVLS :- 6.0.2.0 |
| Product Long Name :- WebSphere MQ for AIX |
| Vendor :- IBM |
| Probe Id :- XC338001 |
| Application Name :- MQM |
| Component :- xehAsySignalHandler |
| SCCS Info :- lib/cs/unix/amqxerrx.c, 1.214.1.4 |
| Line Number :- 737 |
| Build Date :- Sep 21 2006 |
| CMVC level :- p600-200-060921 |
| Build Type :- IKAP - (Production) |
| UserID :- 00000217 (esbuat) |
| Program Name :- runmqlsr_nd |
| Addressing mode :- 64-bit |
| Process :- 897058 |
| Thread :- 2 |
| Major Errorcode :- xecE_W_UNEXPECTED_ASYNC_SIGNAL |
| Minor Errorcode :- OK |
| Probe Type :- MSGAMQ6209 |
| Probe Severity :- 3 |
| Probe Description :- AMQ6209: An unexpected asynchronous signal (1 : |
| SIGHUP) has been received and ignored. |
| FDCSequenceNumber :- 0 |
| Arith1 :- 1 1 |
| Comment1 :- SIGHUP |
| Comment2 :- Signal sent by pid 0 |
| Comment3 :- |
| |
-------------------------------------------------------------------------------------
MQM Function Stack
xehAsySignalMonitor
xehHandleAsySignal
xcsFFST
MQM Trace History
{ xppInitialiseDestructorRegistrations
} xppInitialiseDestructorRegistrations rc=OK
{ xehAsySignalMonitor
-{ xcsGetEnvironmentInteger
--{ xcsGetEnvironmentString
--} xcsGetEnvironmentString rc=xecE_E_ENV_VAR_NOT_FOUND
-} xcsGetEnvironmentInteger rc=xecE_E_ENV_VAR_NOT_FOUND
-{ xcsIsEnvironment
-} xcsIsEnvironment rc=OK
-{ xppPostAsySigMonThread
-} xppPostAsySigMonThread rc=OK
Data: 0x00000001
-{ xehHandleAsySignal
--{ xcsRequestThreadMutexSem
--} xcsRequestThreadMutexSem rc=OK
--{ xcsQueryProcessDetails
---{ xcsGetMem
---} xcsGetMem rc=OK
---{ xcsFreeMem
---} xcsFreeMem rc=OK
--} xcsQueryProcessDetails rc=OK
--{ xcsFFST |
|
| Back to top |
|
|
| bdrummond |
| Posted: Wed Sep 26, 2007 6:33 am Post subject: |
|
|
Disciple
Joined: 06 May 2004
Posts: 164
|
PROBLEM RESOLVED..!!!
An ALTER QMGR command had been performed, changing the CCSID from 819 to 1051.
Changing this back to 819 has resolved the issue.  |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Sep 26, 2007 10:37 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20768
Location: LI,NY
|
| bdrummond wrote: |
PROBLEM RESOLVED..!!!
An ALTER QMGR command had been performed, changing the CCSID from 819 to 1051.
Changing this back to 819 has resolved the issue. |
Thanks for sharing... 
Change of CCSID is not the first thing that comes to mind... Any idea what was the rationale behind the change ?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Sep 26, 2007 7:08 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
I might have expected the error logs on either the client or server to have explicitly mentioned the conversion failure. Can you check back to see whether that did happen?
BTW, a trace would have pinpointed this issue immediately.
1051 is only HP's version of 819, and the AIX server should have a conversion table; dir /usr/lib/nls/loc/iconvTable, ISO8859-1_IBM-1051 & IBM-1051_ISO8859-1.
It is interesting the number of sites where people are allowed mqm access to issue seemingly random runmqsc admin commands. Was there some reason why this command was issued? Now it is changed back, what effect has it had?
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| bdrummond |
| Posted: Thu Sep 27, 2007 12:09 am Post subject: |
|
|
Disciple
Joined: 06 May 2004
Posts: 164
|
The CCSID change was made in error.
The saveqmgr program in support pac MS03 was run on a test QM on a windows machine. The output file was transferred to an AIX box and run with runmqsc.
The CCSID was part of the saveqmgr output file but was not removed before running against the AIX QMgr.
With regards to errors, none were reported that I didn't mention earlier. Or if there were, I couldn't find them.
Now that it has been changed back to 819, the toolkit is able to connect and everything seems to be running as it should.
Thanks for everyones help on this matter. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Thu Sep 27, 2007 12:50 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
I don't think you have got to the bottom of this. If the saveqmgr output was created on Windows, the CCSID would have been 437 or 1252, English with/without Euro, not 1051 which is specific to HP.
Anyway, are you sure you checked the error logs on client and server?
Seems a very elaborate and purposeful user error to me, involving file transfer between different machines.
Glad you have sorted it out.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| bdrummond |
| Posted: Thu Sep 27, 2007 12:57 am Post subject: |
|
|
Disciple
Joined: 06 May 2004
Posts: 164
|
I definitely checked both client and server for error logs and simply couldn't find any errors that described a character set problem.
I never ran the saveqmgr command so only assumed that it would have been done on a windows box. This may not be the case. What do they say about assuming..? 
Oh well, it seems to be working ok now, I'll just have to keep an eye on things to make sure there are no other strange problems. |
|
| Back to top |
|
|
|
|
