Applies to:
Error Message Area:Application Integration Infrastructure, Enterprise Application Interfaces - EAI
Version:Siebel 8.1
Purpose
This document is intended to provide cause and corrective action information about Siebel Error Message SBL-EAI-04233: Unable to connect to MQSeries queue manager '%1' MQSeries error code: %2 Check your MQSeries configuration and verify that the queue manager is running.
Scope
This document is informational and intended for any user.
SBL-EAI-04233: Unable to connect to MQSeries queue manager '%1' MQSeries error code: %2 Check your MQSeries configuration and verify that the queue manager is running.
Explanation
Unable to connect to MQSeries queue manager.
Corrective Action
Check your MQSeries configuration and verify that the queue manager is running.
Applies to:
Siebel System Software - Version: 7.7.2.4 [18365] and later [Release: V7 and later ]
IBM AIX on POWER Systems (64-bit)
Product Release: V7 (Professional)
Version: 7.7.2.4 [18365]
Database: IBM DB2 8.1.3 FixPack 3
Application Server OS: IBM AIX 5L 5.2
Database Server OS: IBM AIX 5L 5.2
This document was previously published as Siebel SR 38-3015750291.
""""Checked for relevance on 29-OCT-2010""""
Symptoms
SBL-EAI-04233, SBL-BPR-00162
MQSeries 5.3 is installed in the Siebel 7.7 application server. A Workflow Process is used to put a message on the queue: TEST.BBB.NEW.CUST.CASE.REQUEST.TO.SIEBEL which is on the queue manager: QM1. When Workflow runs, the following error is reported :-
SBL-EAI-04233: Unable to connect to MQSeries Queue Manager 'QM1' MQSeries Error Code: 2035 Please check your MQSeries configuration and verify that the queue manager is running.
The associated error code is: IDS_EAI_ERR_TRANS_MQ_CONNECT -- SBL-BPR-00162
The queue manager is working and that MQ is functioning properly as it is possible to drop messages on queues and pick them up.
Cause
The 2035 error mentioned is equivalent to MQRC 2035 which indicates that the person is not authorized to perform the function that is attempted.
Solution
Use the dspmqaut (display authority command), to determine if the user has the authorization to access the intended object.
Use the setmqaut (set or reset authority) command, to grant access to WebSphere MQ objects.
For more information to resolve the behavior please see the following posting :-
http://www-1.ibm.com/support/docview.wss?rs=172&context=SW900&q1=mqrc+2035&uid=swg21166937&loc=en_US&cs=utf-8&lang=en+en
Please make sure that Siebel instance owner (which is the account that the Siebel service runs under), can be used to login and run ‘amqsput’ or ‘amqsget’ sample Websphere MQ utilities.
As an alternative, you may also add the operating system user running siebel processes (such as 'siebel') as part of MQM user group.
Applies to:
Siebel Call Center - Version: 8.x - Release: V8
Information in this document applies to any platform.
Symptoms
Customer getting the following error when invoking 'EAI MQSeries Server Transport' business service 'Send' method:
(SBL-BPR-00162)--IDS_EAI_ERR_TRANS_MQ_CONNECT
Error invoking service 'EAI MQSeries Server Transport', method 'Send' at step 'Drop XML to MQ'.(SBL-BPR-00162)
--
Unable to connect to MQSeries Queue Manager 'CMSTEST'
MQSeries Error Code: 2063
Please check your MQSeries configuration and verify that the queue manager is running.(SBL-EAI-04233)
This error did not occur when customer initiated the service call from Windows 2000 platform.
However, when making the same call from a Windows 2003 platform, the above error message was returned.
Changes
Customer has 2 environments with the same Siebel application server, tools, client and MQSeries 6.0 version installed.
The only difference between the two environments are:
Environment in which the call runs successfully, this is on a Windows 2000 platform.
Environment in which the call runs successfully, this is on a Windows 2003 platform.
Cause
Error in customer's case occurs only when running 'EAI MQSeries Server Transport' business service 'Send' method on Windows 2003 OS platform. When customer tested outside of Siebel application with the MQ command 'dspmqaut', they get the following error:
WebSphere MQ was unable to display an error message 7047.
AMQ7047
Thus, this confirms that the connectivity error is occurring even outside of the Siebel application. The connectivity error is occuring within the MQ software.
Error occurs only on Windows 2003 platform due to a known behavior with Windows 2003 security feature. This behaviour has been reported/documented MQSeries vendor website:
1. http://www-1.ibm.com/support/docview.wss?uid=swg21195102
MQRC_SECURITY_ERROR 2063 when connecting to Windows 2003 under userid 'NETWORK SERVICE'
2. http://www-1.ibm.com/support/docview.wss?rs=171&context=SSFKSJ&q1=IC37798&uid=swg1IC37798&loc=en_US&cs=utf-8&lang=en
IC37798: SECURITY ERROR WITH WMQ5.3 AND WINDOWS 2003 SERVER
Problem conclusion
Due to limitations on the operating system calls used to provide the security within WebSphere MQ v5.3, it is not possible to query the group membership of the well known (pre- defined) accounts including the Network Service account.
Therefore it is currently not possible to authorize an application running under this account either by putting it in the mqm group, or via setmqaut.
3. Microsoft IIS v6 users may be able to workaround this problem following instructions here:
http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg21195102
Solution
Please review the above vendor url for details on changes necessary in order to address this behaviour.
If the error still persists with MQ on Windows 2003 properly, then please contact IBM support to correct this behaviour in order for any other applications to connect successfully.
Applies to:
Product Release: V7 (Enterprise)
Version: 7.5.2.214 [16066] Fin Svcs
Database: Oracle 8.1.7.4
Application Server OS: IBM AIX 5L 5.1
Database Server OS: IBM AIX 5L 5.1
This document was previously published as Siebel SR 38-1153677651.
Symptoms
SBL-EAI-04233
Hai,
We having difficulties to bring up our
1. UOB MQ Receiver
2. UOB SCV MQ Receiver
3. UOB WMS MQ Receiver.
after the ML5 activities.
Attached with the error log for your reference.
The server was running fine without any issue before we applied IBM Maintenance Level 5. After we applied the ML5 on last Wednesday, the issue surfaced.
We searched the supportweb and already ensure we followed the suggestion from Supportweb as well.
We did set the IPCBaseAddress=12 on mqs.ini in /var/mqm as recommeded by in the bookshelf
QueueManager:
Name=MUXE08
Prefix=/var/mqm
Directory=MUXE08
IPCCBaseAddress=12
DefaultQueueManager:
Name=MUXE08
After we changed the parameter in siebenv.sh from
export LDR_CNTRL='LOADPUBLIC@MAXDATA=0x60000000' to
export LDR_CNTRL='LOADPUBLIC@MAXDATA=0x40000000'. The problem was resolved.
My question is, all the while in our Development, SIT, UAT as well as Production, we set to
export LDR_CNTRL='LOADPUBLIC@MAXDATA=0x60000000' as recommeded by Siebel, why after applied ML5, we are unable to bring the 3 services as above?
What is the impact if we set it to export LDR_CNTRL='LOADPUBLIC@MAXDATA=0x40000000' instead of
export LDR_CNTRL='LOADPUBLIC@MAXDATA=0x60000000'?
Kindly advice.
Rgds
Solution
Message 1
[1 / 2]
For the benefits of other readers,
This is because that at certain levels before ML05 IBM actually "broke" the large memory model on AIX 5.1. The implication of this was if they had set say " LDR_CNTRL='LOADPUBLIC@MAXDATA=0x60000000' " then it had no effect at all on the executable. For further information, please consult with IBM Technical Support as this is AIX issue.
When applying ML05 it basically will provide the fix for the AIX issue. This would mean that the LDR_CNTRL line springs into life and gives them a setup using 6 segments, which then would collide with the shared memory segment required by the queue manager. It will result in MQSeries fails to start.
To appear to work before ML05 is most likely due to them being on an AIX level that contained the bug causing LDR_CNTRL to have no effect on anything. Siebel application version 7’s siebmtshmw is built with 5-segment heap segments. Segments 2, 3, 4, 5, 6, and 7 hold the stack (2) and 5 heap (3, 4, 5, 6, and 7) segments. Mainsoft default uses segment 3 and MQSeries default uses segment 8.
Hence, if they alter MAXDATA via LDR_CNTRL to use 6 segments for heap Siebel then utilizes segment 8 to, which is used by MQSeries.
(Cont) ...
Message 2
[2 / 2]
In order to get around this behavior, first in our Siebel environment file siebenv.sh they can set
export MW_GMA_VADDR=0xb0000000
This puts mainsoft shared segments at 0xb, 0xc (11, 12)
For MQSeries, they can adjust the /var/mqm/mqs.ini file as follows:
QueueManager:
IPCCBaseAddress=14
This puts the MQSeries shared memory segment address at 0xe. Please note to use 14 they need to be using the AIX variable EXTSHM. By using EXTSHM they can place MQSeries at segment 14.
The alternative is to leave MQSeries default and run with only 5 segments for heap by setting MAXDATA=0x50000000.
Kind Regards,
Siebel Technical Support
אין תגובות:
הוסף רשומת תגובה