The DLQ handler rules table on z/OS

The DLQ handler rules table defines how the DLQ handler is to process messages that arrive on the DLQ.

There are two types of entry in a rules table:

  • The first entry in the table, which is optional, contains Control data.
  • All other entries in the table are rules for the DLQ handler to follow. Each rule consists of a pattern (a set of message characteristics) that a message is matched against, and an action to be taken when a message on the DLQ matches the specified pattern. There must be at least one rule in a rules table.

Each entry in the rules table comprises one or more keywords.

See Rules table conventions on z/OS for information about the syntax of the rules table.

See Rules (patterns and actions) for information about how the pattern-matching, and action keywords control the CSQUDLQH utility


Control data

This section describes the keywords that we can include in a control-data entry in a DLQ handler rules table.

  • All keywords are optional.
  • If a control-data entry is included in the rules table, it must be the first entry in the table.
  • The default value for a keyword, if any, is underlined.
  • The vertical line (|) separates alternatives. We can specify only one of these.

    INPUTQ (QueueName|' ')
    Specifies the name of the DLQ that we want to process:
    1. If you specify a queue name in the PARM parameter of the EXEC statement, this overrides any INPUTQ value in the rules table.
    2. If we do not specify a queue name in the PARM parameter of the EXEC statement, the INPUTQ value in the rules table is used.
    3. If we do not specify a queue name in the PARM parameter of the EXEC statement or the rules table, the dead-letter queue named qmgr-name.DEAD.QUEUE is used if it has been defined. If this queue does not exist, the program fails and returns error message CSQU224E, giving the reason code for the error.

    INPUTQM (QueueManagerName|' ')
    Specifies the name of the queue manager that owns the DLQ named on the INPUTQ keyword.
    1. If you specify a queue manager name in the PARM parameter of the EXEC statement, this overrides any INPUTQM value in the rules table.
    2. If we do not specify a queue manager name in the PARM parameter of the EXEC statement, the INPUTQM value in the rules table is used.
    3. If we do not specify a queue manager name in the PARM parameter of the EXEC statement or the rules table, the default queue manager is used (if one has been defined using CSQBDEFV). If not, the program fails and returns error message CSQU220E, giving the reason code for the error.

    RETRYINT (Interval|60)
    Specifies the interval, in seconds, at which the DLQ handler should attempt to reprocess messages on the DLQ that could not be processed at the first attempt, and for which repeated attempts have been requested. The DLQ handler reprocesses messages after it has first browsed to the end of the queue.

    The default is 60 seconds.

    WAIT (YES|NO| nnn)
    Specifies whether the DLQ handler should wait for further messages to arrive on the DLQ when it detects that there are no further messages that it can process.

      YES
      The DLQ handler waits indefinitely.

      NO
      The DLQ handler terminates when it detects that the DLQ is either empty or contains no messages that it can process.

      nnn
      The DLQ handler waits for nnn seconds for new work to arrive after it detects that the queue is either empty or contains no messages that it can process, before terminating.

      Specify a value in the range 1 through 999 999.

    Specify WAIT (YES) for busy DLQs, and WAIT (NO) or WAIT ( nnn ) for DLQs that have a low level of activity. If the DLQ handler is allowed to terminate, we can use triggering to invoke it when needed.

Parent topic: The dead-letter queue handler utility (CSQUDLQH) on z/OS