Middleware News

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

Directory structure (Windows systems) Table 1 shows the directories found under the root c:\Program Files\IBM\WebSphere MQ\. If you have installed WebSphere® MQ for Windows under a different directory, the root is modified appropriately. Table 1. WebSphere MQ for Windows directory structure\bin     Contains binary files (commands and DDLs). \config     Contains configuration information. \conv     Contains files for data conversion in folder \table. \errors     Contains the system error log files:     AMQERR01.LOG     AMQERR02.LOG     AMQERR03.LOG These files contain information related errors that are not associated with a particular queue manager. AMQERR01.LOG contains the most recent error information. This folder also holds any FFST™ files that are produced. \exits     Contains channel exit programs. \licenses     Contains a folder for each national language. Each folder contains license information. \log     Contains a folder for each queue manager. The fo

This information applies to WebSphere MQ running on UNIX systems only. If you run a process in the background, that process can be given a higher nice value (and hence lower priority) by the invoking shell. This might have general WebSphere MQ performance implications. In highly-stressed situations, if there are many ready-to-run threads at a higher priority and some at a lower priority, operating system scheduling characteristics can deprive the lower priority threads of CPU time. It is strongly recommended that independently started processes associated with queue managers, such as runmqlsr, have the same nice values as the queue manager they are associated with. Ensure the shell does not assign a higher nice value to these background processes. For example, in ksh, use the setting "set +o bgnice" to stop ksh from raising the nice value of background processes. You can verify the nice values of running processes by examining the NI column of a "ps -efl" listi

The AIX model for System V shared memory differs from other UNIX platforms, in that a 32-bit process can only attach to 10 WebSphere MQ memory segments concurrently. A typical 32-bit WebSphere MQ application requires two WebSphere MQ memory segments attached for every connected queue manager. Every additional connected queue manager requires one further WebSphere MQ memory segment attached. Note: During the MQCONN operation an additional shared memory segment is required. In a threaded process where multiple threads are connecting to the same queue manager, you must ensure an additional memory segment is available for every connected queue manager. A 64-bit process is not limited to attaching to only 10 WebSphere MQ memory segments concurrently. A typical 64-bit WebSphere MQ application requires three WebSphere MQ memory segments for every connected queue manager. The connection of additional queue managers typically requires two further WebSphere MQ memory segments for every conn

When a WebSphere MQ queue manager is ended normally, the queue manager removes the majority of the IPC resources that it was using. A small number of IPC resources remain and this is as designed: some of the IPC resources are intended to persist between queue manager restarts. The number of IPC resources remaining varies to some extent, depending on the operating conditions.End of change Start of changeThere are some situations when a larger proportion of the IPC resources in use by a queue manager might persist after that queue manager has ended:     If applications are connected to the queue manager when it stops (perhaps because the queue manager was shut down using endmqm -i or endmqm -p), the IPC resources used by these applications might not be released.     If the queue manager ends abnormally (for example, if an operator issues the system kill command), some IPC resources might be left allocated after all queue manager processes have terminated. In these cases, the IPC r

The following table lists the CipherSpecs supported by WebSphere MQ. Specify the CipherSpec name in the SSLCIPH property of the SVRCONN channel on the queue manager and in MQEnvironment.SSLCipherSpec Table 1. Supported CipherSpecsCipherSpec DES_SHA_EXPORT DES_SHA_EXPORT1024 NULL_MD5 NULL_SHA RC2_MD5_EXPORT RC4_56_SHA_EXPORT1024 RC4_MD5_US RC4_MD5_EXPORT RC4_SHA_US TRIPLE_DES_SHA_US

You have WebSphere MQ clients which connect to several different MQ servers. The MQ clients are quite frequently disconnected with rc=2009, MQRC_CONNECTION_BROKEN. The clients are able to reconnect immediately. The queue managers are running well. You see no problems when issuing 'runmqsc' commands on the server. Symptom On the MQ server side you see the following message in the queue manager's error log, AMQERR01.LOG: AMQ9213: A communications error for TCP/IP occurred. EXPLANATION: An unexpected error occurred in communications. ACTION: The return code from the TCP/IP(select) [TIMEOUT] 660 seconds call was 11 (X'B'). Record these values and tell the systems administrator. Cause There was a parameter recently added in your qm.ini file called ClientIdle that was set to 600 secs. This caused the client connections to end after they were idle for the specified period of time + 60 seconds. After the connection is terminated at the server, the next a