Oninit
Talk to an expert →

Informix Error -75: No message of desired type.

Cause and resolution

No message of desired type.

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 errno values whose meanings vary between Unix platforms and versions. Confirm the native errno definition 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 — No message of desired type 75 ENOMSG — STREAMS/IPC-era
The same symbol on modern Linux 42 ENOMSG — No message of desired type (exact text match)
Errno 75 on Linux 75 EOVERFLOW — Value too large for defined data type, unrelated 
python3 -c 'import errno, os; print(42, os.strerror(42)); print(75, os.strerror(75))'

The catalogue text matches modern Linux's ENOMSG message word-for-word, a strong signal the symbol identification is right — but the number Informix's catalogue uses (75) is still not modern Linux's number (42) for that same symbol. The exact originating platform/era for the number 75 specifically isn't independently confirmed here; treat it the same as -70/-71's established pattern and verify against the actual reporting host.

What ENOMSG Actually Tells You

ENOMSG means a message-queue-style receive operation asked for a message of a specific type and none of that type was available in the queue at the time — even though the queue itself may hold other messages of different types. This is a selective-receive miss, not "the queue is empty" and not "the queue/endpoint doesn't exist."

What This Means in Informix

Per the official text, this is an OS-level error code reaching the database server unexpectedly. Historically this class of condition is associated with STREAMS message-typed reads (getmsg(2)-style calls that can filter by message type) or System V message queues (msgrcv(2) with a type selector) — mechanisms used for certain forms of interprocess communication rather than for ordinary file or socket I/O. If Informix (or a component it depends on) issued a type-selective receive expecting a particular message type to be pending, and none was, this is the resulting error.

Common Causes
  1. A type-selective receive call finding no message of the requested type — the direct, named cause; the underlying queue or endpoint itself is otherwise functioning normally.
  2. A timing/ordering issue where the expected message hasn't arrived yet at the moment of the receive call, rather than never arriving at all.
  3. A protocol mismatch between sender and receiver about which message type identifiers are in use, so a message did arrive but not tagged with the type being requested.
Solutions / Resolution
  1. Retry the operation, per the official guidance's general pattern for these operating-system codes — a timing mismatch between when the message was expected and when it actually arrives is a plausible, self-clearing cause.
  2. If the condition recurs consistently rather than clearing, treat it as a genuine protocol or configuration mismatch rather than a timing fluke, and capture the exact operation/component involved for escalation.
  3. If the problem persists, note all circumstances and contact IBM Informix Technical Support, per the official guidance.
Examples
N/A

No specific triggering statement is documented beyond an operating-system error code unexpectedly returned to the database server — the official text gives no further detail.

Diagnostic Checks
  1. Confirm the symbol and its native value on the reporting host:
    python3 -c 'import errno, os; print(42, os.strerror(42)); print(75, os.strerror(75))'
  2. Check what operation/component was involved, via the accompanying online log entries around the same timestamp.
  3. Check whether retrying the same operation clears the condition, distinguishing a timing miss from a persistent mismatch.
Related Errors / Related Topics
  • -70 — Stale NFS file handle. Same operating-system-errno cluster, same platform-dependent-numbering caveat.
  • -71 — Too many levels of remote in path. Same cluster, same caveat.
  • -74 — Out of stream resources. Adjacent STREAMS-era symbol, a resource-exhaustion condition rather than -75's selective-receive miss.

A type-selective message receive that found nothing matching at that moment — retry, and treat a persistent recurrence as a genuine protocol/configuration mismatch rather than a timing fluke.