MQRC 2080: Message too large for the buffer

What it means

MQGET copies the message into the buffer the program passes, up to BufferLength bytes. If the message is longer and the get options don't include MQGMO_ACCEPT_TRUNCATED_MSG, the call returns completion code MQCC_WARNING with reason 2080. The message isn't removed from the queue.

The call still gives the program what it needs to recover. DataLength holds the full length of the message, the buffer holds as much of the message as fit, and the message descriptor (MQMD) is filled in. For a browse, the browse cursor doesn't move. The program can allocate a bigger buffer and get the message again.

If the program sets MQGMO_ACCEPT_TRUNCATED_MSG, the get removes the message, returns the part that fit and reports 2079 (MQRC_TRUNCATED_MSG_ACCEPTED). The rest of the message is lost. That is only right when the program really needs just the start of each message.

Common causes

• The program uses a fixed buffer sized for typical messages, and a larger message arrived, for example after a sender added fields or started batching records.
• A COBOL or PL/I copybook defines a buffer for the old record layout, and the sending system now writes longer records.
• The program passes BufferLength smaller than the buffer it actually allocated.
• An unexpected message arrives on the queue, such as a report message or a message from a different application.

How to find the problem

1. Log DataLength after the 2080. It gives the real length of the message, so you can compare it with BufferLength.
2. Browse the message with amqsbcg or dmpmqmsg on distributed MQ, or a browse tool on z/OS, and check its format, put application name and length.
3. Check where BufferLength is set in the program and whether it matches the size of the buffer area.
4. Check the MAXMSGL of the queue to know the largest message the program could ever receive.

How to fix it

• On 2080, allocate a buffer of at least DataLength and issue the get again. Match on the MsgId just returned in the MQMD, or use the browse cursor, so you get the same message and not the next one.
• Size the starting buffer to the largest message the application expects, or to the queue's MAXMSGL if storage allows.
• Fix copybooks or record definitions when the message layout changes, and recompile every program that reads the queue.
• Use MQGMO_ACCEPT_TRUNCATED_MSG only when losing the end of a message is acceptable. Otherwise data is silently dropped.

Technical reviewer: Albert Joseph, WND Software.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s MQ documentation for your version.