Making initial checks on z/OS
Before you start problem determination in detail, consider whether there is an obvious cause of the problem, or an area of investigation that is likely to give useful results. This approach to diagnosis can often save a lot of work by highlighting a simple error, or by narrowing down the range of possibilities.
The cause of your problem could be in:
- IBM® MQ
- The network
- The application
- Other applications that you have configured to work with IBM MQ
This section contains a list of questions to consider. As you go through the list, make a note of anything that might be relevant to the problem. Even if your observations do not suggest a cause straight away, they might be useful later if you have to carry out a systematic problem determination exercise.
- Has IBM MQ for z/OS run successfully before?
- Have you applied any APARs or PTFs?
- Are there any error messages, return codes or other error conditions?
- Has your application or IBM MQ for z/OS stopped processing work?
- Is there a problem with the IBM MQ queues?
- Are some of your queues working?
- Are the correct queues defined?
- Does the problem affect only remote or cluster queues?
- Does the problem affect only shared queues?
- Does the problem affect specific parts of the network?
- Problems that occur at specific times of the day or affect specific users
- Is the problem intermittent or does the problem occur with all z/OS, CICS, or IMS systems?
- Has the application run successfully before?
- Have any changes been made since the last successful run?
- Do you have a program error?
- Has there been an abend?
- Have you obtained incorrect output?
- Can you reproduce the problem?
- Have you failed to receive a response from an MQSC command?
- Is your application or IBM MQ for z/OS running slowly?
See the following sections for some additional tips for problem determination for system administrators and application developers.
Tips for system administrators
- Check the error logs for messages for your operating system:
- Check the contents of qm.ini for any configuration changes or errors. For more information on changing configuration information, see:
- If your application development teams are reporting something unexpected, you use trace to investigate the problems. For information about using trace, see Using trace.
![[Windows]](ngwin.gif)
![[UNIX]](ngunix.gif)
![[Linux]](nglinux.gif)
![[IBMi]](ngibmi.gif)
![[z/OS]](ngzos.gif)
Tips for application developers
- Check the return codes from the MQI calls in your applications. For a list of reason codes, see API completion and reason codes. Use the information provided in the return code to determine the cause of the problem. Follow the steps in the Programmer response sections of the reason code to resolve the problem.
- If you are unsure whether your application is working as expected, for example, you are not unsure of the parameters being passed into the MQI or out of the MQI, you can use trace to collect information about all the inputs and outputs of your MQI calls. For more information about using trace, see Using trace.
- For more information about handling errors in MQI applications, see Handling program errors.