Oninit
Talk to an expert →

Informix Error -74

Cause and resolution

Out of stream resources.

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 — Out of stream resources 74 ENOSR — STREAMS-era
The same symbol on modern Linux 63 ENOSR — Out of streams resources (near-exact text match)
Errno 74 on Linux 74 EBADMSG — Not a data message, unrelated (this is coincidentally -76's own catalogue text — see Related, below) 
python3 -c 'import errno, os; print(63, os.strerror(63)); print(74, os.strerror(74))'

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

What ENOSR Actually Tells You

ENOSR means a STREAMS-based operation needed kernel STREAMS resources — internal buffers, message blocks, or queue structures the STREAMS subsystem allocates to service stream I/O — and none were available at the moment of the request. Unlike ENOSTR (-72, no STREAMS capability at all) this means the STREAMS mechanism itself is present and in use; it's just momentarily out of the resources needed to service another request.

This is typically a transient exhaustion condition, not a permanent capability problem — resources freed by other streams closing or draining can make the same operation succeed on retry.

What This Means in Informix

Per the official text, this is an OS-level resource-exhaustion condition reaching the database server unexpectedly. Historically, on STREAMS-based platforms this could surface around:

  • A high number of concurrent STREAMS-backed connections or terminal sessions, each consuming STREAMS resources, exhausting a system-wide or per-user limit.
  • STREAMS-based network transport modules under heavy connection load, if the transport itself was implemented over STREAMS on the platform involved.
  • System-wide STREAMS tunables set too low for the actual concurrency the host is asked to support (nstrpush, queue/buffer limits, and similar STREAMS-subsystem tunables on the platforms that expose them).

On modern non-STREAMS platforms this specific mechanism generally isn't in play; if this error still appears on a current install, it's worth confirming what STREAMS-backed device or transport (if any) is actually involved before assuming ordinary resource exhaustion (like file descriptor or memory limits) is the cause.

Common Causes
  1. STREAMS kernel resources genuinely exhausted by concurrent load — the direct, named cause.
  2. STREAMS-subsystem tunables configured too low for the host's actual concurrency, on platforms where those tunables exist and are adjustable.
  3. A resource leak on the STREAMS side — streams not being properly closed/drained, gradually consuming available resources until none remain for new requests.
Solutions / Resolution
  1. Retry the operation — per the official guidance's general pattern for these operating-system codes, and consistent with this being typically a transient exhaustion condition rather than a permanent one.
  2. Check the platform's STREAMS-subsystem tunables, if the reporting host exposes them, and raise them if the host's actual concurrency genuinely requires more STREAMS resources than currently configured.
  3. Check for a STREAMS resource leak — connections or sessions that should have released their STREAMS resources but didn't — if the condition recurs rather than clearing after a brief wait.
  4. 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(63, os.strerror(63)); print(74, os.strerror(74))'
  2. Check current STREAMS-related resource usage/tunables, if the platform exposes them.
  3. Check whether the condition clears on retry — supporting transient exhaustion — or recurs immediately, which would point toward a leak or a genuinely undersized configuration.
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.
  • -72 — Not a stream device. Adjacent STREAMS-era symbol — -72 is "no STREAMS capability at all," -74 is "had the capability, ran out of resources for it."

A STREAMS kernel-resource exhaustion condition, typically transient — retry, and check STREAMS-subsystem tunables or a possible resource leak if it recurs.