Home

 

An example DLQ handler rules table

 

The following example rules table contains a single control-data entry and several rules:

************************************************************************* 
*        An example rules table for the runmqdlq command                * 
************************************************************************* 
* Control data entry 
* ------------------ 
* If no queue manager name is supplied as an explicit parameter to 
* runmqdlq, use the default queue manager for the machine. 
* If no queue name is supplied as an explicit parameter to runmqdlq, 
* use the DLQ defined for the local queue manager. 
* 
inputqm(' ')  inputq(' ')   

* Rules 
* ----- 
* We include rules with ACTION (RETRY) first to try to 
* deliver the message to the intended destination.   
* If a message is placed on the DLQ because its destination 
* queue is full, attempt to forward the message to its 
* destination queue. Make 5 attempts at approximately 
* 60-second intervals (the default value for RETRYINT).   

REASON(MQRC_Q_FULL) ACTION(RETRY) RETRY(5)   

* If a message is placed on the DLQ because of a put inhibited 
* condition, attempt to forward the message to its 
* destination queue. Make 5 attempts at approximately 
* 60-second intervals (the default value for RETRYINT).   

REASON(MQRC_PUT_INHIBITED) ACTION(RETRY) RETRY(5)   

* The AAAA corporation are always sending messages with incorrect 
* addresses. When we find a request from the AAAA corporation, 
* we return it to the DLQ (DEADQ) of the reply-to queue manager 
* (&REPLYQM). 
* The AAAA DLQ handler attempts to redirect the message.   

MSGTYPE(MQMT_REQUEST) REPLYQM(AAAA.*) +
  ACTION(FWD) FWDQ(DEADQ) FWDQM(&REPLYQM)   

* The BBBB corporation never do things by half measures. If 
* the queue manager BBBB.1 is unavailable, try to 
* send the message to BBBB.2   

DESTQM(bbbb.1) +
  action(fwd) fwdq(&DESTQ) fwdqm(bbbb.2) header(no)   

* The CCCC corporation considers itself very security 
* conscious, and believes that none of its messages 
* will ever end up on one of our DLQs. 
* Whenever we see a message from a CCCC queue manager on our 
* DLQ, we send it to a special destination in the CCCC organization 
* where the problem is investigated.   

REPLYQM(CCCC.*) + 
  ACTION(FWD) FWDQ(ALARM) FWDQM(CCCC.SYSTEM)   

* Messages that are not persistent run the risk of being 
* lost when a queue manager terminates. If an application 
* is sending nonpersistent messages, it should be able 
* to cope with the message being lost, so we can afford to 
* discard the message.   PERSIST(MQPER_NOT_PERSISTENT) ACTION(DISCARD)   
* For performance and efficiency reasons, we like to keep 
* the number of messages on the DLQ small. 
* If we receive a message that has not been processed by 
* an earlier rule in the table, we assume that it 
* requires manual intervention to resolve the problem. 
* Some problems are best solved at the node where the 
* problem was detected, and others are best solved where 
* the message originated. We don't have the message origin, 
* but we can use the REPLYQM to identify a node that has 
* some interest in this message. 
* Attempt to put the message onto a manual intervention 
* queue at the appropriate node. If this fails, 
* put the message on the manual intervention queue at 
* this node.   

REPLYQM('?*') + 
  ACTION(FWD) FWDQ(DEADQ.MANUAL.INTERVENTION) FWDQM(&REPLYQM)   

ACTION(FWD) FWDQ(DEADQ.MANUAL.INTERVENTION)

 

Parent topic:

The WebSphere MQ dead-letter queue handler

fa14100_

 

Home