Remote queue definition points to wrong target

When Remote queue definition points to wrong target, treat the queue as a buffer, not the problem: depth growing means producers outrun consumers — the queue is the symptom, the consumer is the cause.

What it means

• Backout queues and the dead-letter queue exist so that poison messages never block real work.
• Every MQ call returns a completion code (0=OK, 1=warning, 2=failed) plus a reason — an ignored reason code is a bug.
• A channel in RETRY is a network or security problem between queue managers, not an application problem.

Common causes

• Consumer stopped or too slow while producers keep putting — queue depth climbs.
• Poison message: the application backs it out forever because BOTHRESH and BOQNAME handling is missing.
• Trigger monitor not running, so triggered applications never start.
• Channel stuck in retry after a certificate or firewall change on the remote end.
• Application ignores the reason code and treats a failed MQGET as an empty queue.

How to diagnose

• DISPLAY QSTATUS(queue) CURDEPTH — depth trending upward proves a consumer problem.
• DISPLAY QSTATUS of the dead-letter queue — the DLQ header names the original failure.
• DISPLAY CHSTATUS(*) — shows channels in RETRY or STOPPED with the last error.
• Check backout counts: a message past BOTHRESH belongs on the backout queue.
• Review the code path: every MQPUT and MQGET must check CompCode and Reason.

How to fix it

• Restart or scale the consumer; set MAXDEPTH sensibly so a runaway producer fails fast instead of filling disk.
• Define BOQNAME and BOTHRESH so poison messages divert to the backout queue automatically.
• Start the trigger monitor (runmqtrm) and verify the process definition the trigger points to.
• Fix the channel (certificates, CHLAUTH rules), reset it, then resolve any in-doubt messages.
• Add reason-code checking to the application — a 2085 or 2035 must raise an alert, never loop silently.

Example: MQ health checks

CURDEPTH rising while the consumer runs means the consumer is the bottleneck.

Interview tip

• Q: Queue depth keeps growing but the application reports no errors — similar to Remote queue definition points to wrong target. What is wrong?
• A: The application is almost certainly ignoring the reason code — for example treating MQCC_FAILED with reason 2085 as if the queue were simply empty. I check the CompCode and Reason handling in the code first, confirm depth with DISPLAY QSTATUS, then fix the error handling so failures surface instead of looping silently.

Prevention checklist

• Always define a dead-letter queue, plus a backout queue with BOTHRESH.
• Monitor CURDEPTH trends and channel status; alert well before MAXDEPTH.
• Code review rule: no MQ call ships without CompCode and Reason checks.