MQRC 2079: Truncated message accepted

What it means

The buffer was too small, but MQGMO_ACCEPT_TRUNCATED_MSG allowed the get to complete. The returned buffer holds the part that fits, while DataLength describes the original length.

A destructive get removes the message subject to unit-of-work behavior; a browse advances its cursor. IBM classifies the result as MQCC_WARNING. Treating it as an ordinary failed get can lose the distinction between consumed data and a message still available to retry.

A troubleshooting example

A consumer expects JSON but accepts truncated gets by default. A larger message returns 2079, then parsing fails because the final bytes are missing. A second get retrieves a different message because the first one was already consumed outside syncpoint. Fix the buffer policy and warning classification together. A regression test should verify the message's availability after a too-small-buffer result and should reject partial business data explicitly, rather than depending on a parser failure to notice truncation.

Common causes

• The program intentionally accepts partial messages for a preview or inspection feature.
• A default get-options mask includes accept-truncated behavior even though the consumer requires the full payload.
• Message sizes grew beyond a fixed buffer and the consumer did not inspect warnings.

How to find the problem

1. Record BufferLength, returned DataLength, the get options and whether the call browsed or consumed.
2. Establish whether the get was under syncpoint and whether it was committed or backed out. Preserve the returned partial data safely for diagnosis.
3. Check the consumer's warning-handling path. Determine whether it parsed or acted on the incomplete payload.
4. Test with a message just larger than the buffer and verify queue state afterward. Do not infer retention from a generic exception message.

How to fix it

• For full-message processing, remove accept-truncated behavior and implement a supported sizing or retry approach that preserves the message.
• If the get was destructive under a transaction, follow the application's approved backout path before expecting the complete message to be available again.
• For deliberate previews, mark the data as partial and never send it to business parsers that require the complete document.

What it looks like

Illustrative diagnostic notes; not an IBM message template.
MQGET BufferLength=1024
DataLength=4096 CompCode=MQCC_WARNING Reason=2079
MQGMO_ACCEPT_TRUNCATED_MSG was set.
Check whether the message was consumed and committed.

Technical reviewer: Albert Joseph, WND Software.

Updated 2026-10-23. IBM documentation checked for this article. Written in our own words. For the full reference, check IBM’s MQ documentation for your version.