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 you 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 you 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(R) 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(TM) 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.