Reprocessing MFT messages from the reject queue

When a per-message error is encountered, the logger rejects the message by placing the message on the reject queue. You can view the contents of the reject queue, see why a message was rejected, and (in some cases) reprocess the message.

Before you begin

This task assumes that you have read MFT logger error handling and message rejection, and are therefore aware of the following information:
  • When a per-message error is encountered, the logger rejects the message by placing the message on the reject queue. Nothing is written to the output log, so you must periodically inspect or continuously monitor the reject queue to detect rejected messages.
  • If too many messages are rejected consecutively, this is treated as a general error. You can tune the number of consecutive per-message errors needed to cause a general error by using the wmqfte.max.consecutive.reject property.
  • For a stand-alone database logger, the output log is located in the directory MQ_DATA_PATH/mqft/logs/coordination_qmgr_name/loggers/logger_name. For a JEE database logger, it is located in the standard output log of the application server.

About this task

Messages that result in per-message errors are moved to the reject queue. Sometimes, you might want to reprocess messages from the reject queue. In the example described in MFT logger error handling and message rejection, with a two-character job name column in the database, the messages could be successfully processed after the width of the database column had been increased. As another example, when a transfer-complete message is rejected because its associated transfer-start was missing, the transfer-start message might be received later. Reprocessing the transfer-complete will then be successful.

Malformed log messages in the transfer log are not logged by the logger. These messages are not viewed as being significant and so these messages are sent to the reject queue. For more information about transfer log messages, see File transfer log message formats.

Example

On each rejected message, a message property is set to indicate why the message was rejected. The full name of the property is usr.WMQFTE_ReasonForRejection, although usr. is omitted in some contexts (including JMS and the IBM® MQ Explorer). If you are using IBM MQ Explorer, you can view the contents of the reject queue by right-clicking the queue and clicking Browse Messages. To see why a message was rejected, double-click the message to open its properties dialog, then select the Named Properties page. You will see a property called WMQFTE_ReasonForRejection. Alternatively, you could write or configure a monitoring tool to obtain this information automatically.

To reprocess messages, move them from the reject queue to the input queue. In a normal installation, where the logger creates its own managed subscription, the input queue is defined by the queue manager and has a name like SYSTEM.MANAGED.DURABLE.49998CFF20006204. You can identify the input queue by looking at the Destination name in the properties for the subscription SYSTEM.FTE.DATABASELogger.AUTO, or using the following MQSC command: 
 DISPLAY SUB(SYSTEM.FTE.DATABASELogger.AUTO) DEST
One way of moving messages between queues is to use the MA01 SupportPac, for example: 
 q -IFTE.REJECT -oSYSTEM.MANAGED.DURABLE.49998CFF20006204
The reject queue might contain messages rejected for various reasons, only some of which have been resolved. In this case you can still reprocess all the messages; those messages that can now be accepted are consumed, and those messages that cannot are again moved to the reject queue.