Skip to content

Exstream MQ correlation produces null output messages

Historical eraHP Exstream 7.0-era MQ connector

By Tomas Hajek, working with Exstream since 2008. Published 2026-07-09

Applies to: Classic 7.0-era Exstream MQ connector correlation; reported defect behavior with a containment workaround.

Symptom

The log shows USERPROGRAM_EOF_BUT_KEEP_ENGINE_GOING, then the connector reports Synch Mode Error: Multiple reads posted, writing NULL output message. A valid response is written first; after it, repeated 0-byte or null messages land on the output queue. MQ reads return reason code 2033 after the first message.

Correlation settings shuffle the symptom around: CORRELATE=MSG or CORRELATE=CID changes the behavior, and CORRELATIONREPLY=QUEUE_FROM_INPUT_MSG_FIRST suppresses the null messages, but at the cost of losing the correlation identifier the integration needs.

Cause

The connector's synchronous correlation path can post another read after the request has already completed. With no further input available, that extra read becomes a multiple-read condition and the connector emits a null response for it.

This was reported as an open defect in the 7.0-era implementation, together with a separate correlation-ID regression in 7.0.607 and 7.0.608 and a claimed correction in a later maintenance release. Those release boundaries are forum evidence, so revalidate them against your exact engine and connector build.

Fix

As containment, enable the classic SINGLEPACKAGE setting in the MQ initialization file. Verify the change in the log: writing NULL output message should become continue with normal read.

Test with a controlled setup: one input message, one valid output, and an empty queue after the request completes. Critically, confirm the workaround preserves correlation metadata in the output and has not silently switched to queue-first correlation behavior; suppressing the nulls while dropping the correlation ID trades a visible defect for an invisible one.

If the defect reproduces without application changes, the real fix is a maintenance release containing the vendor correction, or a vendor case armed with the message trace and exact connector configuration.

Keep the workaround scoped to this correlation defect

Repeated 2033 reason codes after the first message can mean that the connector polled after the transaction completed. They do not prove malformed input. SINGLEPACKAGE addressed this correlation path, so do not carry it into unrelated MQ configurations.

Related Exstream notes.

Resolve can check the pattern against your environment.

Resolve searches your approved sources and shows its citations. If the evidence is weak, the same case reaches an experienced Exstream specialist with the evidence attached.

These articles describe field experience and identify the Exstream versions they cover. They are not official vendor guidance. CCMForge is independent and is not affiliated with or endorsed by OpenText. OpenText and Exstream are trademarks of their respective owner.