Has the application run successfully before?

If the problem appears to involve one particular application, consider whether the application has run successfully before.

Before you answer Yes to this question, consider the following:

Have any changes been made to the application since it last ran successfully?

If so, it is likely that the error lies somewhere in the new or modified part of the application. Take a look at the changes and see if we can find an obvious reason for the problem.

Have all the functions of the application been fully exercised before?

Could it be that the problem occurred when part of the application that had never been invoked before was used for the first time? If so, it is likely that the error lies in that part of the application. Try to find out what the application was doing when it failed, and check the source code in that part of the program for errors.

If a program has been run successfully on many previous occasions, check the current queue status and files that were being processed when the error occurred. It is possible that they contain some unusual data value that causes a rarely used path in the program to be invoked.

Does the application check all return codes?

Could it be that your system has been changed, perhaps in a minor way, but your application does not check the return codes it receives as a result of the change. For example:

• Does your application assume that the queues it accesses can be shared? If a queue has been redefined as exclusive, can your application deal with return codes indicating that it can no longer access that queue?

• Have any security profiles been altered? An MQOPEN call could fail because of a security violation; can your application recover from the resulting return code?

Does the application expect particular message formats?

If a message with an unexpected message format has been put onto a queue (for example, a message from a queue manager on a different platform) it might require data conversion or another different form of processing.

Does the application run on other WebSphere MQ for z/OS systems?

Could it be that there is something different about the way that this queue manager is set up that is causing the problem? For example, have the queues been defined with the same maximum message length, or default priority?

Does the application use the MQSET call to change queue attributes?

Could it be that, for example, the application is designed to set a queue to have no trigger, then process some work, then set the queue to have a trigger? The application might have failed before the queue had been reset to have a trigger.

Does the application handle messages that cause an application to fail?

If an application fails because of a corrupted message, the message retrieved is rolled back. The next application might get the same message and fail in the same way. Ensure that applications use the backout count; when the backout count threshold has been reached, the message in question is put onto the backout queue.

If your application has never run successfully before, examine your application carefully to see if we can find any of the following errors:

Translation and compilation problems

Before you look at the code, examine the output from the translator, the compiler or assembler, and the linkage editor, to see if any errors have been reported. If your application fails to translate, compile/assemble, or link-edit into the load library, it will also fail to run if you attempt to invoke it. See the WebSphere MQ Application Programming Guide for information about building your application, and for examples of the job control language (JCL) statements required.

Batch and TSO programs

For batch and TSO programs, check that the correct stub has been included. There is one batch stub and two RRS stubs. If you are using RRS, check that you are not using the MQCMIT and MQBACK calls with the CSQBRSTB stub; use the CSQBRRSI stub if you want to continue using these calls with RRS.

CICS programs

For CICS programs, check that the program, the WebSphere MQ CICS stub, and the CICS stub have been linked in the correct order. Also, check that your program or transaction is defined to CICS.

IMS programs

For IMS programs, check that the link includes the program, the WebSphere MQ stub, and the IMS language interface module, and that the correct entry point has been specified. Note that a program that is loaded dynamically from an IMS program must have the stub and language interface module linked also if it is to use WebSphere MQ.

Possible code problems

If the documentation shows that each step was accomplished without error, consider the coding of the application. Do the symptoms of the problem indicate the function that is failing and, therefore, the piece of code in error? See Do you have a program error? for some examples of common errors that cause problems with WebSphere MQ applications.

Do applications report errors from WebSphere MQ?

For example, a queue might not be enabled for "gets". It receives a return code specifying this but does not report it. Consider where your applications report any errors or problems.