Perhaps the preliminary checks have enabled you to find the cause of the problem. If so, you should now be able to resolve it, possibly with the help of other books in the WebSphere MQ library and in the libraries of other licensed programs.
If you have not yet found the cause, start to look at the problem in greater detail. The purpose of this section is to help you identify the cause of your problem if the preliminary checks have not enabled you to find it. When you have established that no changes have been made to your system, and that there are no problems with your application programs, choose the option that best describes the symptoms of your problem.
If none of these symptoms describe your problem, consider whether it might have been caused by another component of your system.
In this book, incorrect output refers to your application:
If messages do not appear when you are expecting them, check for the following:
If messages are being put or retrieved within syncpoint, they are not available to other tasks until the unit of recovery has been committed.
You can set the wait interval as an option for the MQGET call. Ensure that you are waiting long enough for a response.
Check that you are waiting for a message with the correct MsgId or CorrelId. A successful MQGET call sets both these values to that of the message retrieved, so you might need to reset these values in order to get another message successfully.
Also, check whether you can get other messages from the queue.
If not, and WebSphere MQ has been restarted, the message has been lost.
If you cannot find anything wrong with the queue, and WebSphere MQ is running, check the process that you expected to put the message onto the queue for the following:
If it should have been triggered, check that the correct trigger options were specified.
Look for evidence of an abnormal end in the job log.
If multiple transactions are serving the queue, they can conflict with one another. For example, suppose one transaction issues an MQGET call with a buffer length of zero to find out the length of the message, and then issues a specific MQGET call specifying the MsgId of that message. However, in the meantime, another transaction issues a successful MQGET call for that message, so the first application receives a reason code of MQRC_NO_MSG_AVAILABLE. Applications that are expected to run in a multiple server environment must be designed to cope with this situation.
Consider that the message could have been received, but that your application failed to process it in some way. For example, did an error in the expected format of the message cause your program to reject it? If this is the case, refer to Messages that contain unexpected or corrupted information.
If the information contained in the message is not what your application was expecting, or has been corrupted in some way, consider the following:
Ensure that all changes are simultaneously reflected on all systems that need to be aware of the change.
For example, the format of the message data might have been changed, in which case, both applications must be recompiled to pick up the changes. If one application has not been recompiled, the data will appear corrupt to the other.
Check that the messages your application is receiving are not really intended for an application servicing a different queue. If necessary, change your security definitions to prevent unauthorized applications from putting messages on to the wrong queues.
If your application uses an alias queue, check that the alias points to the correct queue.
Check that your application should have started; or should a different application have started?
If these checks do not enable you to solve the problem, check your application logic, both for the program sending the message, and for the program receiving it.
If your application uses distributed queues, consider the following points:
Check that both systems are available, and connected to WebSphere MQ. Check that the connection between the two systems is active.
You can use the MQSC command PING against either the queue manager (PING QMGR) or the channel (PING CHANNEL) to verify that the link is operable.
Check that triggering is activated in the remote system.
If so, check if the message has been put onto the dead-letter queue.
The dead-letter queue header contains a reason or feedback code explaining why the message could not be put onto the target queue. See the WebSphere MQ Application Programming Reference for information about the dead-letter queue header structure.
For example, the message length could be longer than the receiving queue manager can handle.
For example, a mismatch in sequence number wrap can stop the distributed queuing component. See WebSphere MQ Intercommunication for more information about distributed queuing.
If the data format is not recognized for conversion, the data conversion exit is taken to allow you to perform the translation with your own routines.
Refer to the WebSphere MQ Application Programming Guide for further details of data conversion.
If you have issued a command but have not received a response, consider the following:
Work with the dspmqcsv command to check the status of the command server.
The dead-letter queue header structure contains a reason or feedback code describing the problem. See the WebSphere MQ Application Programming Reference for information about the dead-letter queue header structure (MQDLH).
If the dead-letter queue contains messages, you can use the provided browse sample application (amqsbcg) to browse the messages using the MQGET call. The sample application steps through all the messages on a named queue for a named queue manager, displaying both the message descriptor and the message context fields for all the messages on the named queue.
See Error logs for further information.
If your MQGET call has timed out, a completion code of MQCC_FAILED and a reason code of MQRC_NO_MSG_AVAILABLE are returned. (See the WebSphere MQ Application Programming Reference for information about the WaitInterval field, and completion and reason codes from MQGET.)
Unless you have specifically excluded your request message from syncpoint, you need to take a syncpoint before receiving reply messages.
Set the values of MsgId and CorrelId in your application to ensure that you receive all messages from the queue.
Try stopping the command server and then restarting it, responding to any error messages that are produced.
If the system still does not respond, the problem could be with either a queue manager or the whole of the WebSphere MQ system. First, try stopping individual queue managers to isolate a failing queue manager. If this does not reveal the problem, try stopping and restarting WebSphere MQ, responding to any messages that are produced in the error log.
If the problem still occurs after restart, contact your IBM Support Center for help.
If you suspect that the problem occurs with only a subset of queues, check the local queues that you think are having problems:
Check the queue attributes IPPROCS and OPPROCS. These attributes indicate whether the queue has been opened for input and output. If a value is zero, it indicates that no operations of that type can occur. The values might have changed; the queue might have been open but is now closed.
You need to check the status at the time you expect to put or get a message.
If you are unable to solve the problem, contact your IBM Support Center for help.
If the problem affects only remote queues:
If your application is running slowly, it might be in a loop or waiting for a resource that is not available.
This might also indicate a performance problem. Perhaps your system is operating near the limits of its capacity. This type of problem is probably worst at peak system load times, typically at mid-morning and mid-afternoon. (If your network extends across more than one time zone, peak system load might seem to occur at some other time.)
A performance problem might be caused by a limitation of your hardware.
If you find that performance degradation is not dependent on system loading, but happens sometimes when the system is lightly loaded, a poorly-designed application program is probably to blame. This could appear to be a problem that only occurs when certain queues are accessed.
The following symptoms might indicate that WebSphere MQ is running slowly:
If the performance of your system is still degraded after reviewing the above possible causes, the problem might lie with WebSphere MQ itself. If you suspect this, contact your IBM Support Center for help.
If you are using AIX, consider setting your tuning parameter to exploit full performance for nonpersistent messages. To set this tuning parameter, a root user must issue the command /usr/samples/kernal/vmtune -c 0.
The effect of this command persists until the next reboot. An AIX administrator can add a line such as vmtune:2:once:/usr/samples/kernal/vmtune -c 0 to the system /etc/inittab file to cause the command to be issued on every reboot. This command is made available by installing the bos.adt.samples fileset from the AIX installation CDs.
Normally, nonpersistent messages are kept only in memory, but there are circumstances where AIX can schedule nonpersistent messages to be written to disk. Messages scheduled to be written to disk are unavailable for MQGET until the disk write completes. The suggested tuning command varies this threshold; instead of scheduling messages to be written to disk when 16 kilobytes of data are queued, the write-to-disk occurs only when real storage on the machine becomes close to full.