This section contains information about resolving problems related to WebSphere MQ. For additional information on WebSphere MQ see the InterChange Server installation manuals and the InterChange Server System Administration Guide. The following topics are covered:
"Errors related to queue configuration"
"Failures to create new instances of MQQueueManager"
"Failure recovery and the queue manager"
"Memory checker segmentation fault"
WebSphere MQ may report errors if the configuration settings for the queues do not allow for a sufficient number of messages, a sufficient maximum length for messages, or a sufficient size for log files. For information about adjusting these configuration settings, see "Configuring WebSphere MQ Message Queues" in the System Installation Guide.
On the AIX platform, the use of the bindings transport (C via JNI) in JDK 1.3.1_06 requires some additional configuration to avoid a conflict with shared memory segments. If the configuration is not done, a failure to create a new instance of MQQueueManager, with reason code 2059, can occur. The failure can be accompanied by the generation of FDCs in the /var/mqm/errors directory.
To perform the configuration, use an additional parameter for the mqs.ini file. The parameter is IPCCBaseAddress and is set on a per queue manager basis. By default this parameter is set to the value 8, but it is recommended that you set this value to 12. The following is an example of an altered QueueManager stanza in an mqs.ini file:
QueueManager: Name=MQJavaTest Prefix=/var/mqm IPCCBaseAddress=12
After a full system failure and recovery, the queue manager might fail to start, displaying this message:
AMQ7017 Log not available.
This typically indicates that the log file is missing or damaged, or that the log path to the queue manager is inaccessible.
To remedy the problem, create a dummy queue manager and copy its header log file and transaction log files over to the actual queue manager. This will allow you to restart the queue manager.
On the AIX platform, the memory checker thread can get a segmentation fault when JMS or other modules are used in WebSphere MQ binding mode.
By default, Java 1.4.2 runs using eight segments. (Eight is the maximum value allowed; each segment is 256 MB). You can reduce the number of segments Java uses with the LDR_CNTRL environment variable.
The setting of the LDR_CNTRL=MAXDATA environment variable value is linked to the size of the heap used by the JVM. To simplify the setting of LDR_CNTRL=MAXDATA, the JVM sets an appropriate value that is based on the maximum size of the heap. If LDR_CNTRL=MAXDATA is set before you start the JVM, the JVM uses the specified value. Otherwise, the JVM uses the following algorithm to set LDR_CNTRL=MAXDATA:
On AIX v5.2 or later:
If the heap size is 3 GB or greater, LDR_CNTRL=MAXDATA=0@DSA is set. If the heap size is between 2.3 GB and 3 GB, LDR_CNTR=MAXDATA=0XB0000000@DSA is set. If the heap size is less than 2.3GB, LDR_CNTR=MAXDATA=0XA0000000@DSA is set.
On AIX v5.1:
If the heap size is greater than 1 GB, LDR_CNTRL=MAXDATA is set to an appropriate value. Note that this is an inverse relationship because as the the heap size increases, fewer segments are reserved through the LD_CNTRL=MAXDATA value. For example for a 1 GB heap LDR_CNTRL=MAXDATA is set to 0X60000000, while for a 1.5 GB heap, the LDR_CNTRL=MAXDATA value is 0X40000000. If the heap sizes is smaller than 1 GB, LDR_CNTRL=MAXDATA is set to 0X80000000.
If your native methods use a large amount of shared memory (for example, with functions like shmat() and mmap()), you might need to reduce the number of segments used by Java. You might also find that you need to reduce the number of segments used by Java when concurrently running Java with other applications that use shared memory, particularly those that explicitly specify the address where a shared memory segment is attached (rather than letting AIX choose the address).