Identifying characteristics of the problem on IBM i

If you have not been able to identify the cause of the problem by using the preliminary checks, you should now start to look at the characteristics of the problem in greater detail.

1. Can you reproduce the problem?
   If you can reproduce the problem, consider the conditions under which you do so:

   • Is it caused by a command? Does the operation work if it is entered by another method? If the command works if it is entered on the command line, but not otherwise, check that the command server has not stopped. You must also check that the queue definition of the SYSTEM.ADMIN.COMMAND.QUEUE has not been changed.
   • Is it caused by a program? If so, does it fail in batch? Does it fail on all IBM MQ for IBM i systems, or only on some?
   • Can you identify any application that always seems to be running in the system when the problem occurs? If so, examine the application to see if it is in error.
   • Does the problem occur with any queue manager, or when connected to one specific queue manager?
   • Does the problem occur with the same type of object on any queue manager, or only one particular object? What happens after this object has been cleared or redefined?
   • Is the problem independent of any message persistence settings?
   • Does the problem occur only when sync points are used?
   • Does the problem occur only when one or more queue manager events are enabled?
2. Is the problem intermittent?
   An intermittent problem might be caused by failing to take into account the fact that processes can run independently of each other. For example, a program might issue an MQGET call, without specifying a wait option, before an earlier process has completed.

   You might also encounter this problem if your application tries to get a message from a queue while the call that put the message is in-doubt (that is, before it has been committed or backed out).

3. Are you receiving errors when you use special characters in commands?
   To avoid potential problems with special characters be careful when including special characters, for example backslash (\) and quotation marks (") characters, in descriptive text for some commands. If you use either of these characters in descriptive text, precede them with a backslash (\) character, for example:

   • Enter \\ if you need a backslash (\) character in your text.
   • Enter \" if you need quotation marks (") characters in your text.

   Queue managers and their associated object names are case-sensitive. By default, IBM i uses uppercase characters, unless you surround the name in apostrophe (') characters. For example, MYQUEUE and myqueue translate to MYQUEUE, whereas 'myqueue' translates to myqueue.

4. Does the problem affect all users of the IBM MQ for IBM i application?
   If the problem affects only some users, look for differences in how the users configure their systems and queue manager settings.

   Check the library lists and user profiles. Can the problem be circumvented by having *ALLOBJ authority?

5. Does the problem affect specific parts of the network?
   You might be able to identify specific parts of the network that are affected by the problem (remote queues, for example). If the link to a remote message queue manager is not working, the messages cannot flow to a remote queue. Check these points:

   • Is the connection between the two systems available, and has the intercommunication component of IBM MQ for IBM i started? Check that messages are reaching the transmission queue, the local queue definition of the transmission queue, and any remote queues.
   • Have you made any network-related changes that might account for the problem or changed any IBM MQ for IBM i definitions?
   • Can you distinguish between a channel definition problem and a channel message problem? For example, redefine the channel to use an empty transmission queue. If the channel starts correctly, the definition is correctly configured.
6. Does the problem occur only on IBM MQ?
   If the problem occurs only on this version of IBM MQ, check the appropriate database on RETAIN, or the https://www.ibm.com/support/entry/portal/Overview/Software/WebSphere®/WebSphere_MQ, to ensure that you have applied all the relevant PTFs.
7. Does the problem occur at specific times of the day?

   If the problem occurs at specific times of day, it might be that it is dependent on system loading. Typically, peak system loading is at mid-morning and mid-afternoon, and so these times are when load-dependent problems are most likely to occur. (If your IBM MQ for IBM i network extends across more than one time zone, peak system loading might seem to occur at some other time of day.)

8. Have you received no response from a command?
   If you have issued a command but you have not received a response, consider the following questions:

   • Is the command server running? Work with the DSPMQMCSVR command to check the status of the command server.
     • If the response to this command indicates that the command server is not running, use the STRMQMCSVR command to start it.
     • If the response to the command indicates that the SYSTEM.ADMIN.COMMAND.QUEUE is not enabled for MQGET requests, enable the queue for MQGET requests.
   • Has a reply been sent to the dead-letter queue? The dead-letter queue header structure contains a reason or feedback code describing the problem. See MQDLH - Dead-letter header 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.
   • Has a message been sent to the error log? For more information, see Error logs on IBM i.
   • Are the queues enabled for put and get operations?
   • Is the WaitInterval long enough? 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 Getting messages from a queue using the MQGET call for more information about the WaitInterval field, and completion and reason codes from MQGET.)
   • If you are using your own application program to put commands onto the SYSTEM.ADMIN.COMMAND.QUEUE, do you need to take a sync point? Unless you have excluded your request message from sync point, you must take a sync point before attempting to receive reply messages.
   • Are the MAXDEPTH and MAXMSGL attributes of your queues set sufficiently high?
   • Are you using the CorrelId and MsgId fields correctly? Set the values of MsgId and CorrelId in your application to ensure that you receive all messages from the queue.