Middleware News

List of processes and what they typically control for MQ: 1. RUNMQLSR - MQ TCP listener (multi-threaded) 2. AMQCLMAA - MQ TCP listener (single-threaded) 3. AMQRMPPA - Channel process pooling job 4. RUNMQCHI - MQ channel initiator 5. AMQCRSTA - MQ receiving MCA jobs 6. RUNMQCHL - MQ sending MCA jobs 7. AMQCRS6B - LU62 receiver channel 8. AMQPCSEA - MQ command server 9. RUNMQTRM - Application trigger monitor 10. RUNMQDLQ - Dead letter queue handler 11. AMQFCXBA - MQ Broker Worker Job 12. RUNMQBRK - MQ Broker Control Job 13. AMQZMUC0 - MQ Utility Manager 14. AMQZMUR0 - MQ Utility Manager 15. AMQZMGR0 - MQ Process Controller 16. AMQRRMFA - MQ cluster repository manager 17. AMQZDMAA - MQ deferred message manager 18. AMQALMPX - MQ Log Manager 19. AMQZFUMA - MQ Object Authority Manager 20. AMQZLAS0 - MQ Local Queue Manager agents 21. AMQZLAA0 - MQ Local Queue Manager agents 22. AMQZXMA0 - MQ Execution Controller

Your JMS application runs on IBM WebSphere® Application Server to connect to a WebSphere MQ messaging system receives an MQJMS2005 error with reason code 2059. Cause Reason code 2059 means that the queue manager is not available. The most likely cause of the problem is that the queue manager is not running or that the queue manager listener is not running. Another possible cause is that the queue manager name that is specified on the JMS connection factory is incorrect. Resolving the problem These are some steps to take to try to resolve the cause of the 2059 error. Confirm that the queue manager is up and running and that the listener is running Ensure that the queue manager is running. You can use the  dspmq  command to verify this. The status of the queue manager should be Running . Check the MQ FDC files in the  MQ_install_root /errors and  MQ_install_root /qmgrs/ queue_manager_name /errors directories to see what relevant error messages may be logged there.

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

You have WebSphere MQ v5.3 CSD04 or MQ 6 or MQ 7.0 installed on AIX with 6 queue managers created. Two queue managers are sending queue managers and the remaining 4 are receiving queue managers. When the sender send data to the receiving queue manager, that queue manager reject the data and produce the following error and the FDC listed below. AMQ6119 with rc=27 meaning EFBIG "File too big" on both Sending and Receiving queue managers. Cause Probe AD020000 is caused by an attempt to increase the queue file size beyond the Operating System limit (ulimit). Resolving the problem Increase the /etc/security/limits to go beyond 1GB. Three things have to occur to over come the 1 GB limit: Enable large file support. Increase the ulimit values to match the MQ limit or to unlimited. Create the queue after you have enabled large file support. As stated from the System Administration Guide - "Enabling large queues WebSphere MQ Version 5.3 supports queues larg

Problem(Abstract) Your Queue manager fails to start due to an authorization problem, return code = 5 (ERROR_ACCESS_DENIED). Symptom AMQ7019: An error occurred while creating the directory structure for the new queue manager. Trace shows the failure occurs in zutCheckDirectory, with return code = 5 (ERROR_ACCESS_DENIED). Cause The domain User-ID under, which MQSeries services is running has not been authorized to access the shared disk. Resolving the problem Update the file permissions on the shared disk to authorize the MQ administrative User-ID to have "Full Control" to the shared disk. Verify the mqm group has "Full Control" to the shared disk. AMQ7019 when creating a queue manager (crtmqm)   Problem(Abstract) When trying to create a queue manager using "crtmqm", you receive the following error: AMQ7019: An error occurred while creating the directory structure for the new queue manager. The FDC shows Probe "ZT071000&qu

WebSphere MQ V7.5 delivers a single Universal Messaging solution. It enables the simple, rapid, reliable, and secure transport of data and messages between applications, systems, and services. WebSphere MQ is the market-leading, message-oriented middleware product that delivers a reliable, proven universal messaging backbone for almost 10,000 organizations of different sizes, spanning many industries around the world Customers gain access to previously separately installable capabilities, enabling more complete solutions for data and message movement along with reduced complexity. Get the advantage of a smaller install footprint, simpler maintenance and eliminate the need for separate packages. Add as you need. Enhancements include Integrated Managed File Transfer – WebSphere MQ File Transfer Edition, previously available separately, is now integrated as an optional feature of WebSphere MQ server component as WebSphere Managed File Transfer Service. Additional separately ins

dspmqinf Display WebSphere® MQ configuration information (Windows and UNIX platforms only). Purpose Use the dspmqinf command to display WebSphere MQ configuration information. Optional parameters -s StanzaType The type of stanza to display. If omitted, the QueueManager stanza is displayed. The only supported value of StanzaType is QueueManager. -o stanza Displays the configuration information in stanza format as it is shown in the .ini files. This format is the default output format. Use this format to display stanza information in a format that is easy to read. -o command Displays the configuration information as an addmqinf command. Information about the installation associated with the queue manager is not displayed using this parameter. The addmqinf command does not require information about the installation. Use this format to paste into a command shell. Return codes Return code Description 0 Successful operation 39 Bad command-line parameters 44 Stanza

dspmqver New types of information are displayed by dspmqver to support multiple installations. The changes might affect existing administrative scripts you have written to manage WebSphere® MQ. The changes in output from dspmqver that might affect existing command scripts that you have written are twofold: Version 7.5 has extra -f field options. If you do not specify a -f option, output from all the options is displayed. To restrict the output to the same information that was displayed in earlier releases, set the -f option to a value that was present in the earlier release. Compare the output for dspmqver in Figure 1 and Figure 2 with the output for dspmqver -f 15 in Figure 3. Figure 1. Default dspmqver options in WebSphere MQ version 7.0.1 dspmqver Name:        WebSphere MQ Version:     7.0.1.6 CMVC level:  p701-L110705 BuildType:   IKAP - (Production) Figure 2. Default dspmqver options in WebSphere MQ version 7.5 dspmqver Name:        WebSphere MQ Version:     7.1

You can also specify the maximum number of active channels. You can do this to prevent your system being overloaded by a large number of starting channels. If you use this method, you should set the disconnect interval attribute to a low value to allow waiting channels to start as soon as other channels terminate. Each time a channel that is retrying attempts to establish connection with its partner, it must become an active channel. If the attempt fails, it remains a current channel that is not active, until it is time for the next attempt. The number of times that a channel will retry, and how often, is determined by the retry count and retry interval channel attributes. There are short and long values for both these attributes. See Channel attributes for more information. When a channel has to become an active channel (because a START command has been issued, or because it has been triggered, or because it is time for another retry attempt), but is unable to do so because the

You can set server-connection channel limits to prevent client applications from exhausting queue manager channel resources and to prevent a single client application from exhausting server-connection channel capacity. A maximum total number of channels can be active at any time on an individual queue manager, and the total number of server-connection channel instances are included in the maximum number of active channels. If you do not specify the maximum number of simultaneous instances of a server-connection channel that can be started, then it is possible for a single client application, connecting to a single server-connection channel, to exhaust the maximum number of active channels that are available. When the maximum number of active channels is reached, it prevents any other channels from being started on the queue manager. To avoid this, you must limit the number of simultaneous instances of an individual server-connection channel that can be started, regardless of whi

Use the  Channels  queue manager properties page from the WebSphere® MQ Explorer, or the  CHANNELS stanza in the qm.ini file, to specify information about channels. MaxChannels= 100 | number The maximum number of channels allowed. The default is 100. MaxActiveChannels= MaxChannels_value The maximum number of channels allowed to be active at any time. The default is the value specified on the  MaxChannels  attribute. MaxInitiators= 3 | number The maximum number of initiators.  The default and maximum value is 3. Any value greater than 3 will be taken as 3. MQIBindType=FASTPATH| SHARED The binding for applications: FASTPATH Channels connect using  MQCONNX  FASTPATH; there is no agent process. SHARED Channels connect using SHARED. PipeLineLength= 1 | number The maximum number of concurrent threads a channel will use. The default is 1. Any value greater than 1 is treated as 2. When you use pipelining, configure the queue managers at both ends of the channel to hav

mq                                                            

Directory structure (UNIX systems) Figure 1 shows the general layout of the data and log directories associated with a specific queue manager. The directories shown apply to the default installation. If you change this, the locations of the files and directories are modified accordingly. For information about the location of the product files, see one of the following:     WebSphere MQ for AIX® Quick Beginnings     WebSphere MQ for HP-UX Quick Beginnings     WebSphere MQ for Solaris Quick Beginnings     WebSphere MQ for Linux Quick Beginnings In Figure 1, the layout is representative of WebSphere® MQ after a queue manager has been in use for some time. The actual structure that you have depends on which operations have occurred on the queue manager. Figure 1. Default directory structure (UNIX systems) after a queue manager has been started Default directory structure after a queue manager has been started (UNIX systems). By default, the following directories and files are located in t