Middleware News

When you configure inetd or xinetd with WebSphere MQ 5.3 for Linux on Intel or zSeries systems, you may find that the amqcrsta TCP/IP responder program will fail with an FDC showing Probe Id XY439010 from Component xcsProgramInit. Cause The FDC will show a Major Errorcode of MQRC_ENVIRONMENT_ERROR, which means that it is not running with the threading model that MQ expects. WebSphere MQ V5.3 uses the LinuxThreads model rather than the newer NPTL threading model available on many newer Linux distributions. Resolving the problem Configure WebSphere MQ to use LinuxThreads by setting the following environment variable wherever the queue manager, its programs, or user applications will run: export LD_ASSUME_KERNEL=2.4.19 Be aware that this variable can cause problems for some applications which require NPTL threading. In particular, refer to the item on RPM database corruption when using this environment variable. For this reason the IBM® MQ programs can use an alternate v

After you upgrade from WebSphere MQ V6 to V7, many instances of the errors AMQ6090 and AMQ5037 are shown in the queue manager error logs. Symptom The following errors are shown in the WMQ queue manager error logs. AMQ6090: WebSphere MQ was unable to display an error message 6287. EXPLANATION: MQ has attempted to display the message associated with return code hexadecimal '6287'. The return code indicates that there is no message text associated with the message. Associated with the request are inserts 0 : 0 : AMQ5037: The Queue Manager task 'ERROR-LOG' has started. EXPLANATION: The Utility Task Manager, process ID (708760) type(203), has started the ERROR-LOG task. Meanwhile, FDC files are generated which correspond to the AMQ5037 errors: | Probe Id :- XC022001 | Component :- xcsDisplayMessage | Program Name :- amqzmur0 | Major Errorcode :- zrcX_TASK_STARTED | Probe Type :- MSGAMQ5037 | Probe Description :- AMQ5037: The Queue Manager task 'ER

You install WebSphere MQ for Linux . You try to create a queue manager using the crtmqm command and It fails because it could not open the MQSeries message catalog (amq.cat). Symptom [mqm mqm]$ crtmqm -q F.QMGR AMQ6090 WebSphere MQ was unable to open a message catalog to display an error message for message id hexadecimal %6, with inserts %1, %2, %3, %4, and % 5. Cause Directory /usr/share/locale/C , had insufficient permissions (700). Resolving the problem Change directory /usr/share/locale/C to 555 (r-xr-xr-x). These problems are generally permissions problems. Verify the file permissions on the WebSphere MQ message catalog (amq.cat) and every directory element for the path. By default the WebSphere MQ message catalog will be in: /usr/share/locale/ /LC_MESSAGES/amq.cat Note: Substitute your language for

Your queue manager ended as a result of the server being rebooted. You restarted your queue manager and noticed many FDCs with probe id XC338001, component xehAsySignalHandler: Symptom Example of FDC: Probe Id :- XC338001 Component :- xehAsySignalHandler Major Errorcode :- xecE_W_UNEXPECTED_ASYNC_SIGNAL Comment1 :- SIGTERM +------------------------------------------------------- MQM Function Stack xehAsySignalMonitor xehHandleAsySignal xcsFFST Cause The server was rebooted without first shutting down the queue manager. Resolving the problem This is working as designed. You need to shut down your Queue Managers before rebooting the system to avoid these FDC reports. Additional information Usually there were many reports of this type of FDC from various WebSphere MQ processes and all these reports were created within a few seconds. The server was rebooted without shutting down the queue manager. Under these conditions it is expected, and desirable behavio

In the reported case, MQRC_ENVIRONMENT_ERROR 2012 is coming from the local queue manager when a WebSphere MQ Java client attempts to do an MQCTL call. Symptom Suddenly the WebSphere Application Server (WSAS) stops getting messages from the MQ queue. The WSAS control region log contains: JMSCMQ0002: The method 'MQCTL' failed. Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2012' ('MQRC_ENVIRONMENT_ERROR'). Cause A slip dump showed that the async consume thread TCB ended. In logrec, the TCB hit an ABENDS0D7 RC25 abend in BMC module MQTRFGST followed by an ABENDS0C1 in BMC module MMAHPCST. The S0D7 and S0C1 are the reason for the async consume thread ending, which causes the MQCTL to fail with MQRC 2012. Diagnosing the problem A slip was provided by the support center to get a dump in CSQBSRV when the MQRC 2012 occurs. Resolving the problem Recycling

 The memory % in "show load" can be significantly higher than the memory % in "show memory". Why are they different? What do they mean? Symptom The WebSphere DataPower WebGUI status value "System Usage "(CLI command " show load ") has a memory % that can be significantly higher than the status value "Memory Usage " (CLI command " show memory" ) memory %. What accounts for this discrepancy? Cause When you display "Memory Usage " from webGUI, notice the various categories of memory values: Total Memory Used Memory Free Memory Requested Memory Hold Memory The memory value in "Memory Usage" from the webGUI (" show memory " in CLI command) is based on Used Memory / Total Memory. The memory value in System Usage from the webGUI (" show load" in CLI command) is derived by Requested Memory / c

This occurs when a WebSphere MQ server is configured to connect to an unsupported version of WebSphere MQ. In this situation, any attempt by a JMS application to send a message to a service integration bus destination that is a defined to a WebSphere MQ server bus member results in a long list of exception messages. The CWSJP0019E message indicates that it is a version problem: com.ibm.ws.sib.remote.mq.exceptions.CorruptRMQSessionException: CWSJP0019E: An attempt to connect to WebSphere MQ using the information that is provided by the WebSphere MQ Server bus member MQServer1-BUS1 resulted in a connection to a WebSphere MQ queue manager running on version MQCMDL_LEVEL_600 on platform MQPL_WINDOWS_NT. This configuration is not supported. Destinations that are assigned to the WebSphere MQ Server bus member are not accessible.   Verify that you have configured the WebSphere MQ server to interoperate with a supported version of WebSphere MQ. For interoperation with WebSph

If a WebSphere MQ link sender channel does not have any messages to deliver, it waits for its specified disconnect interval before timing out. If the application server is shut down while a WebSphere MQ link sender channel is in a wait state, the application server waits for the WebSphere MQ link sender channel to time out before shutting down. A long disconnect interval might delay the server shutdown. If the application server shutdown is delayed by a WebSphere MQ link sender channel in a wait state, you have two options: Attempt to put a message onto the transmission item stream for the WebSphere MQ link sender channel. Note that this might not take the channel out of its wait state if the application server shutdown is already in progress Force the termination of the application server process. To reduce possible delays during application server shutdown, you can specify a smaller value for the disconnect interval. Note that a discount interval of 0 indicates an indefinite

Note: Error messages appear in the SystemOut.log file or, if you have turned on tracing, in the trace.log file. You can also look for equivalent messages in the WebSphere MQ error logs (or trace files if you have turned on tracing in the WebSphere MQ network). If you are sending messages from a service integration bus to a WebSphere MQ network, it is possible that the messages are stored on the service integration bus and waiting to be delivered, but that the WebSphere MQ link sender channel has not been started or is in a retry state. Verify that the WebSphere MQ link sender channel is started and in running state. If you are sending messages from a WebSphere MQ network to a service integration bus, it is possible that the messages are stored on the transmission queue in the WebSphere MQ network and waiting to be delivered, but that the sender channel in the WebSphere MQ network has not been started or is in a retry state. Verify that the sender channel in the WebSp

Note: Error messages appear in the SystemOut.log file or, if you have turned on tracing, in the trace.log file.  New feature: This topic references one or more of the application server log files. Beginning in WebSphere Application Server Version 8.0 you can configure the server to use the High Performance Extensible Logging (HPEL) log and trace infrastructure instead of using SystemOut.log , SystemErr.log , trace.log , and activity.log files or native z/OS logging facilities. If you are using HPEL, you can access all of your log and trace information using the LogViewer command-line tool from your server profile bin directory. Read the "Using HPEL to troubleshoot applications" topic in the Troubleshooting section for more information on using HPEL. Verify that the channel names specified on the WebSphere MQ link sender channel and/or the MQLinkReceiver definitions match those specified on the sender and/or receiver channel definitions in the WebSphere MQ ne

You are running WebSphere MQ on Solaris. You have two machines, one with a MQ client, and the other machine with a queue manager. You have a client application which checks to see if the queue manager is available, by doing a MQCONNX. You have noticed a delay in the response from the MQCONNX. In the situation where the queue manager is stopped, your client receives a reason code 2059 MQRC_Q_MGR_NOT_AVAILABLE, but this is taking as long as 4 minutes. Symptom In the amqerr01.log of the client the following message is seen: AMQ9202: Remote host '11.2.34.555 (1414)' not available, retry later. EXPLANATION: The attempt to allocate a conversation using TCP/IP to host '12.3.45.678(1414)' was not successful. However the error may be a transitory one and it may be possible to successfully allocate a TCP/IP conversation later. ACTION: Try the connection again later. If the failure persists, record the error values and contact your systems administrator. The return code