Do you have a program error?

Use this topic to investigate if a program error is causing an IBM® MQ problem.

The examples that follow illustrate the most common causes of problems encountered while running IBM MQ programs. Consider the possibility that the problem with your system could be caused by one of these errors.
  • Programs issue MQSET to change queue attributes and fail to reset attributes of a queue. For example, setting a queue to NOTRIGGER.
  • Making incorrect assumptions about the attributes of a queue. This assumption could include assuming that queues can be opened with MQOPEN when they are MQOPEN-exclusive, and assuming that queues are not part of a cluster when they are.
  • Trying to access queues and data without the correct security authorization.
  • Linking a program with no stub, or with the wrong stub (for example, a TSO program with the CICS® stub). This can cause either a long-running unit of work, or an X'0C4' or other abend.
  • Passing incorrect or invalid parameters in an MQI call; if the wrong number of parameters are passed, no attempt can be made to complete the completion code and reason code fields, and the task is abended. (This is an X'0C4' abend.)

    This problem might occur if you attempt to run an application on an earlier version of MQSeries® than it was written for, where some of the MQI values are invalid.

  • Failing to define the IBM MQ modules to z/OS® correctly (this error causes an X'0C4' abend in CSQYASCP).
  • Failing to check return codes from MQI requests.

    This problem might occur if you attempt to run an application on a later version of IBM MQ than it was written for, where new return codes have been introduced that are not checked for.

  • Failing to open objects with the correct options needed for later MQI calls, for example using the MQOPEN call to open a queue but not specifying the correct options to enable the queue for subsequent MQGET calls.
  • Failing to initialize MsgId and CorrelId correctly.

    This error is especially true for MQGET.

  • Using incorrect addresses.
  • Using storage before it has been initialized.
  • Passing variables with incorrect lengths specified.
  • Passing parameters in the wrong order.
  • Failing to define the correct security profiles and classes to RACF®.

    This might stop the queue manager or prevent you from carrying out any productive work.

  • Relying on default MQI options for a ported application.

    For example, z/OS defaults to MQGET and MQPUT in sync point. The distributed-platform default is out of sync point.

  • Relying on default behavior at a normal or abnormal end of a portal application.

    On z/OS, a normal end does an implicit MQCMIT and an abnormal end does an implicit rollback.