Informix Error -76: Not a data message.
Cause and resolution
Not a data message.
An operating-system error code with the meaning shown was unexpectedly returned to the database server. If the error recurs, note all circumstances and contact IBM Informix Technical Support.
Oninit® Troubleshooting Guidance
This is an operating-system error number, not an Informix diagnosis.
The same errno is returned by many different operations, so on its own it says what the operating system refused, not what Informix was trying to do. Informix will usually have reported a more specific error alongside it — in the message log, in the SQL or ISAM error pair, or in the accompanying assert failure — and that error normally defines the real cause far more precisely than the errno does. Find it before diagnosing from this number alone.
This matters less than it used to. Later versions of the engine trap many of these conditions and report them as specific Informix errors naming the operation, the object and the context, so a bare errno in this range is increasingly a sign of an older version, an unusual code path, or a failure early in startup before the better reporting is available. If you are seeing one on a current version, the more specific error is worth looking for even harder.
Important platform note. Error codes in this range represent operating-system
errnovalues whose meanings vary between Unix platforms and versions. Confirm the nativeerrnodefinition on the server where the Informix error occurred before diagnosing the problem from the number alone.
Determine the Native Error Meaning
| Value | Symbol | |
|---|---|---|
| Catalogue text — Not a data message | 76 | EBADMSG on the catalogue's source platform |
| The same condition on Linux | 74 | EBADMSG — Not a data message |
| Errno 76 on Linux | 76 | ENOTUNIQ — Name not unique on network, unrelated |
python3 -c 'import os; print(76, os.strerror(76)); print(74, os.strerror(74))'
What EBADMSG Actually Tells You
EBADMSG is a STREAMS-era condition: a process called getmsg(), putmsg(), or an
equivalent STREAMS-based read on a stream head and received (or attempted to send) a message
whose type didn't match what the call expected. STREAMS messages carry a type tag —
ordinary data, a protocol/control message, or a high-priority control message — and the
various getmsg/putmsg variants are picky about which types they'll accept. A read()-style
call landing on a control message where it expected data (or vice versa) is refused rather than
silently reinterpreted.
This is a framing/protocol mismatch between what a STREAMS-based transport delivered and what the caller was prepared to consume — not a corrupted message and not a permissions issue.
What This Means in Informix
Per the official text, this is an OS-level error code surfacing to the database server unexpectedly rather than something Informix generates deliberately. STREAMS-based transports were far more central to Unix networking stacks (particularly for TLI/XTI-based connectivity) in the era this errno range comes from than they are on modern platforms, so this is most plausible where a STREAMS-based connectivity path is still in play:
- A STREAMS-based network transport module (TLI/XTI, or a vendor-specific STREAMS driver used for a connectivity option) returning a message of an unexpected type to the layer above it.
- A pipe or transport implemented over STREAMS on platforms where that's still the case, encountering a framing mismatch between what one end sent and what the other end's read call expected.
- An unexpected message arriving out of sequence — a control message where a data message was expected, most often surfacing during connection setup/teardown on a STREAMS-based transport rather than during steady-state data transfer.
Common Causes
- A STREAMS-based transport module delivering a message of an unexpected type, per the official guidance's framing — the direct, only named cause.
- Protocol version or configuration mismatches on a STREAMS-based connectivity path, causing one end to emit control traffic the other end's read call isn't prepared to accept at that point in the exchange.
- A driver-level bug or misconfiguration in a STREAMS module sitting in the path between Informix and the network.
Solutions / Resolution
- Note all circumstances and contact IBM Informix Technical Support, per the official guidance — this is a low-level transport condition without a documented end-user workaround.
- Check whether a STREAMS-based connectivity option (TLI/XTI, or a platform-specific transport driver) is in use, and whether that platform has newer driver/patch levels available — this class of error is a classic symptom of an outdated or mismatched STREAMS module.
- If the error is reproducible, capture a protocol-level trace on the connection in question before escalating — the exact message type involved is often the fastest way for support to identify which layer is misbehaving.
Examples
N/A
No specific triggering statement is documented — this is a low-level STREAMS transport condition rather than something raised from a particular SQL or application operation.
Diagnostic Checks
- Confirm the symbol, since errno 76 means something unrelated on Linux:
python3 -c 'import os; print(76, os.strerror(76)); print(74, os.strerror(74))' - Identify whether a STREAMS-based transport is actually in the connection path on the affected platform before assuming this is network-related at all.
- Capture full circumstances (the connectivity option in use, platform, and driver/patch level) for escalation to IBM Informix Technical Support.
Related Errors / Related Topics
- -70 — Stale NFS file handle. A different network-adjacent OS errno in the same numeric cluster, unrelated in mechanism.
- -71 — Too many levels of remote in path. Another OS errno neighbor; also unrelated in mechanism, just numerically adjacent.
- -75 — "No message of desired type." A closely related STREAMS message-type condition —
-75 (
ENOMSG) is about a message type not existing at all where requested, while -76 (EBADMSG) is about a message of the wrong type arriving where a different type was expected.
A STREAMS transport delivered a message of an unexpected type — check whether a STREAMS-based connectivity option is involved, and escalate to IBM Informix Technical Support with full circumstances if it recurs.