When triggering does not work

A program is not triggered if the trigger monitor cannot start the program or the queue manager cannot deliver the trigger message. For example, the ApplId in the process object must specify that the program is to be started in the background; if this is not done, the trigger monitor cannot start the program.

If a trigger message is created but cannot be put on the initiation queue (for example, because the queue is full or the length of the trigger message is greater than the maximum message length specified for the initiation queue), the trigger message is put instead on the dead-letter (undelivered message) queue.

If the put operation to the dead-letter queue cannot complete successfully, the trigger message is discarded and a warning message is sent to the console (z/OS) or to the system operator (iSeries), or put on the error log.

Putting the trigger message on the dead-letter queue may generate a trigger message for that queue. This second trigger message is discarded if it adds a message to the dead-letter queue.

If the program is triggered successfully but abends before it gets the message from the queue, use a trace utility (for example, CICS AUXTRACE if the program is running under CICS) to find out the cause of the failure.

How CKTI detects errors

If the CKTI trigger monitor in WebSphere MQ for z/OS detects an error in the structure of a trigger message, or if it cannot start a program, it puts the trigger message on the dead-letter (undelivered message) queue. CKTI adds a dead-letter header structure (MQDLH) to the trigger message. It uses a feedback code in the Reason field of this structure to explain why it put the message on the dead-letter (undelivered message) queue.

An instance of CKTI stops serving an initiation queue if it attempts to get a trigger message from the queue and finds that the attributes of the queue have changed since it last accessed that queue. The attributes could have been changed by another program, or by an operator using the commands or operations and control panels of WebSphere MQ. CKTI produces an error message, which includes a reason code, explaining the action it has taken.

How CSQQTRMN detects errors

If the CSQQTRMN trigger monitor in WebSphere MQ for z/OS detects an error in the structure of a trigger message, or if it cannot start a program, it puts the trigger message on the dead-letter (undelivered message) queue and sends a diagnostic message to a user specified LTERM (the default is MASTER). CSQQTRMN adds a dead-letter header structure (MQDLH) to the trigger message. It uses a feedback code in the Reason field of this structure to explain why it put the message on the dead-letter (undelivered message) queue. If any other errors are detected, CSQQTRMN sends a diagnostic message to the specified LTERM, and then terminates.

How RUNMQTRM detects errors

If the RUNMQTRM trigger monitor in MQSeries for OS/2 Warp and WebSphere MQ on UNIX systems detects an error in either the:

or it either:

it puts the trigger message on the dead-letter (undelivered message) queue, having added a dead-letter header structure (MQDLH) to the message. It uses a feedback code in the Reason field of this structure to explain why it put the message on the dead-letter (undelivered message) queue.



© IBM Corporation 1993, 2002. All Rights Reserved