MQRC 2048: Persistent messages not allowed

What it means

The persistence setting is valid, but the destination does not support it. Temporary dynamic queues cannot hold persistent messages. Persistence inherited from the queue default can trigger the same mismatch as an explicit persistent setting.

On z/OS, IBM also documents persistent puts to a shared queue whose coupling-facility structure is configured with RECOVER(NO). Keep the platform-specific case separate from temporary reply-queue design.

A troubleshooting example

A server correctly preserves the persistence of a business request, but the requester supplies a temporary dynamic reply queue. The server's reply fails with 2048. Fixing only the server by forcing nonpersistent replies changes the delivery guarantee. Agree whether the requester needs durable replies; if it does, give it a suitable durable return destination and cleanup process. A meaningful test includes requester restart and delayed replies, not just a fast request-and-response exchange.

Common causes

• A server copies a persistent request's persistence to a reply addressed to a temporary dynamic queue.
• Queue-default persistence changed while the producer still requests queue-default behavior.
• A z/OS shared-queue design uses a CF structure that does not support the required recovery behavior.

How to find the problem

1. Capture the effective message persistence, including whether MQMD requested the queue default. Read the actual destination definition.
2. For replies, trace ReplyToQ back to the request sender and establish whether it created a temporary or permanent queue.
3. Determine whether 2048 was returned locally or arrived in report or dead-letter information after remote delivery.
4. For shared queues on z/OS, ask the systems programmer to inspect the associated CFSTRUCT recovery configuration and the application's durability requirement.

How to fix it

• If durable replies are required, use an appropriate predefined or permanent dynamic reply queue with a supported lifecycle.
• Use nonpersistent delivery only when the application contract permits it. Do not weaken durability merely to make the put return success.
• Coordinate changes to queue defaults and shared-queue recovery with affected applications. Test request, reply and restart behavior together.

What it looks like

Illustrative diagnostic notes; not an IBM message template.
Request persistence: MQPER_PERSISTENT
Reply destination: temporary dynamic queue
Reply MQPUT Reason=2048
Reconcile durability and reply-queue lifetime.

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.