Have any changes been made since the last successful run?

When you are considering changes that might recently have been made, think about WebSphere MQ, and also about the other programs it interfaces with, the hardware, and any new applications. Consider also the possibility that a new application that you don't yet know about might have been run on the system.

Has your initialization procedure been changed?

Consider whether that might be the cause of the problem. Have you changed any data sets, or changed a library definition? Has z/OS been initialized with different parameters? In addition, check for error messages sent to the console during initialization.

Have you changed any queue definitions or security profiles?

Consider whether some of your queues have been altered so that they are members of a cluster. This might mean that messages arrive from different sources (for example, other queue managers or applications).

Have you changed any definitions in your sysplex that relate to the support and implementation of shared queues?

Consider the effect that changes to such definitions as your sysplex couple data set, or Coupling Facility resource management policy might have on the operation of shared queues. Also, consider the effect of changes to the DB2 data sharing environment.

Has any of the software on your z/OS system been upgraded to a later release?

Consider whether there are any necessary post-installation or migration activities that we need to perform.

Has your z/OS subsystem name table been changed?

Changes to levels of corequisite software like z/OS or LE might mean that you have to also make some changes to WebSphere MQ.

Do your applications deal with return codes that they might get as a result of any changes you have made?

Ensure that your applications deal with any new return codes that you introduce.